Skip to main content
Project-level API keys allow your project to authenticate external systems and trigger workflows securely. This page includes both keys created specifically for this project and any keys inherited from the organization.

​
How API Keys Work at the Project Level

There are two types of keys that may appear in this list:

​
1. Project-Level Keys

These are keys created directly inside the project.
They only apply to this project and cannot be shared with others.

​
2. Organization-Level Keys (Inherited)

If an API key is created at the organization level and its access is set to:
  • All Projects, or
  • Selected Projects, including this one
…then the key automatically becomes available in the project’s API Keys page. Inherited keys behave exactly like project-level keys, except:
  • They can only be edited or deleted from the organization-level API Keys page
  • Their scope and expiry settings are managed at the org level
  • They remain visible here for convenience and use

​
Creating an API Key

Select Create API Key to generate a new project-level key.
You will be asked to configure:
  • Name: A label to help identify the purpose of the key
  • Scope: Defines what the key is allowed to do. Currently, the only available scope is Trigger Workflows, which allows the key to initiate workflow executions via API.
  • Expiry Policy: Determines how long the key remains valid Options include no expiry or fixed durations (e.g., 7–90 days)
Once created, the key will be displayed one time only.

​
One-Time Key Display

Immediately after creation, the key appears in a secure dialog:
  • You can copy the key using the provided button
  • The value cannot be viewed again after the dialog is closed
  • Store the key securely — treat it like any other sensitive secret
If the key is lost, you’ll need to create a replacement key.

​
Managing Keys

From the table of API keys, you may:
  • View basic metadata (name, scope, access settings, etc.)
  • Delete project-level keys created within this project
  • Use either project-level or inherited keys in external integrations
Organization-level keys shown here cannot be deleted at the project level.

​
Best Practices

  • Use project-level keys for project-specific systems or integrations
  • Use organization-level keys for shared systems that must access multiple projects
  • Apply expiry policies based on the security standards of your deployment
  • Rotate keys periodically when possible