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

# Set up a Fireworks AI connector

> Connect Fireworks AI to C1 to govern users, service accounts, roles, and API keys.

C1 provides identity governance for Fireworks AI. The connector syncs account
members, machine identities, role assignments, and API key metadata.

## Capabilities

| Resource | Sync | Provision |
| - | - | - |
| Accounts | | |
| Users | | |
| Service accounts | | |
| Roles and assignments | | |
| API keys | | |

## Gather Fireworks AI credentials

> [!WARNING]
>
> The API key must belong to a Fireworks AI account administrator. Other roles
> can view users and service accounts, but only administrators can manage users
> and access, and list and delete other users' API keys. Credential issuance
> requires permission to list, create, and delete API keys for the target
> service account.

**Step 1**

Sign in to Fireworks AI and open the
[API keys page](https://app.fireworks.ai/account/api-keys).

**Step 2**

Create an API key for an account administrator and copy it. Fireworks only
shows the complete key when it is created.

**Step 3**

Copy the Fireworks account ID. You can find it in the account selector or
run `firectl account get`.

## Configure the Fireworks AI connector

**Cloud-hosted**

Follow these instructions to use the connector hosted by C1.

**Step 1**

In C1, navigate to **Integrations** > **Connectors** and click **Add connector**.

**Step 2**

Search for **Fireworks AI** and click **Add**.

**Step 3**

Choose how to set up the connector, set its owner, and click **Next**.

**Step 4**

In **Settings**, click **Edit** and enter:

* **Account ID**: The Fireworks account ID to sync.
* **API key**: The API key owned by an account administrator.
* **Base URL**: Leave empty unless C1 support gives you a different Fireworks API URL.

**Step 5**

Click **Save**.

**Step 6**

The connector's label changes to **Syncing**, followed by **Connected**.
Review the connector logs if the status does not change to **Connected**.

**Done.** The Fireworks AI connector is now pulling identity and access data into C1.

**Self-hosted**

Configure the connector with these environment variables:

* `BATON_ACCOUNT_ID`: The Fireworks account ID to sync.
* `BATON_TOKEN`: The API key owned by an account administrator.
* `BATON_BASE_URL`: Optional API base URL override. The default is `https://api.fireworks.ai`.

Deploy the connector using your standard self-hosted connector process.

## Provisioning behavior

When you set up account provisioning for users in C1, map values to these fields:

| Field | Required | Description |
| - | - | - |
| `email` | No | The user's email address. Fireworks derives the user ID from it. Defaults to the provisioned user's primary email. |
| `display_name` | No | The Fireworks display name. Defaults to the account login. |
| `role` | No | One of `admin`, `user`, `contributor`, `inference-user`, or `custom` (case-insensitive). Defaults to `user`. |
| `permission_preset` | Only when `role` is `custom` | The Fireworks permission preset for the custom role. |

We recommend leaving `email` unmapped. The connector then uses the provisioned
user's primary email, then their first email, then the login if it is an email
address. If none of these is available, account creation fails before any
Fireworks call. A mapped, non-empty `email` takes precedence over all of them.

The connector uses this email to check whether the user already exists in
Fireworks. If you map `email` to anything other than the user's own email
address, a user who already exists in Fireworks gets a second user.

C1 does not create service accounts. Create them in Fireworks; C1 syncs them,
and you can grant them roles and issue them API keys.

* Assigning a standard role replaces the principal's current Fireworks role.
  Custom role assignments are sync-only because the public API does not expose
  the permission presets required to configure them. Fireworks requires every
  user and service account to have exactly one role, so the connector does not
  offer a role-only revoke operation.
* Deleting an API key removes the key permanently.
* Issue an API key for an existing service account, optionally with an
  expiry time. API key issuance is not available for human users, because
  Fireworks does not allow an administrator's API key to create keys for other
  human users. The connector returns the one-time key value encrypted for the
  requester and syncs only key metadata. Issued keys can be deleted by their
  Fireworks key ID. Before every issuance, the connector lists all pages of the
  owner's API keys. This adds listing requests and confirms list access, which
  is needed for key discovery and later revocation checks. If the listing fails
  or access is denied, issuance stops before creating a key.
  If Fireworks returns an unusable key or ignores the requested
  expiry, the connector attempts to delete the created key before failing issuance.
  When the response omits its key ID, cleanup requires a single new matching key
  in the owner's API-key listing. If cleanup cannot be confirmed, or creation
  fails without a response, inspect the owner's API keys before retrying.

Fireworks exposes user deletion through `firectl`, but its public REST API does
not document a delete-user operation. The connector therefore does not delete
users or service accounts.

Fireworks groups are provisioned from an identity provider through SCIM and do
not have a public list API. This connector does not sync groups.