> ## Documentation Index
> Fetch the complete documentation index at: https://docs.heybreez.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# API Keys

Organization-level API keys allow external systems to trigger workflows securely.

These keys are typically used for integrating HeyBreez with CRMs, backend services, or custom applications.

***

## Overview

The API Keys page lists all keys created at the organization level.\
For each key, you can see general details such as:

* Its name
* Whether it applies to the entire organization or specific projects
* Its current status (active or inactive)
* Its expiry policy

You can create new keys or delete existing ones at any time.

***

## Creating an API Key

Click **Create API Key** to open the creation modal. 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).
* **Project Access**: Controls which projects the key can interact with:
  * **All Projects** — the key applies to every project in the organization (including future projects).
  * **Selected Projects Only** — the key is restricted to specific projects you choose.

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.) of all API keys created at the organization level *and* at the project level
* **Delete any key** when no longer needed

***

## Best Practices

* Use **organization-level keys** for shared systems that must access multiple projects
* If you want to create a key for a project-specific system or integration, create it on the **project level**, not on the organization level
* Apply expiry policies based on the security standards of your deployment
* Rotate keys periodically when possible

*(Full API usage documentation coming soon)*