API Key Management

Not part of the public API surface

Creating, listing, revoking, or deleting API keys are not routes on api.fenicia.io. Those operations live exclusively on the auth host (account.fenicia.io, singular) and today are only consumed by the Fenicia dashboard — they are not a supported public endpoint you can call directly from your integration. The supported path is generating and managing your keys from the web dashboard.

Generating an API key

1

Sign in to your Fenicia dashboard

Open app.fenicia.io and sign in with your email and password.

2

Open Settings → API Keys

In the left sidebar, click Settings, then API Keys. You'll see the list of existing keys, or an empty state if this is your first time.

3

Create a new key

Click + Create API key in the top-right corner.

4

Name the key and choose its scopes

The creation form asks for two things:

  • Name: identifies the key's purpose, e.g. Production - My integration.
  • Scopes: the resources and permissions the key can use (see Permissions and scopes).

There is no expiration date field in the form. The backend does support an optional expiration, but it isn't exposed in the creation UI today — if you don't set one, the key never expires.

5

Copy the key immediately

Shown only once

Fenicia only returns the full key value in the creation response. No other screen — not the list, not the detail view — shows it again. If you lose it, there's no way to retrieve it: you'll need to generate a new one.

6

Store it in your environment

Never hardcode it into your source code. Read it from an environment variable:

# .env
FENICIA_API_KEY=fkapi_1m8x2z9k_3f9a1c2d4e5f6789abcd0123ef456789
Settings → API Keys. This is where you manage every API key for your account.

Real key format

Every API key Fenicia generates follows a single format, produced by exactly one generator across the whole system:

fkapi_{base36 timestamp}_{uuid v4, no dashes}

Example: fkapi_1m8x2z9k_3f9a1c2d4e5f6789abcd0123ef456789

Key limit per tenant

Each tenant can have a maximum of 10 active API keys at a time. This is a fixed, hardcoded limit that doesn't vary by plan. If you try to create an 11th key while 10 are active, creation fails — revoke or delete an unused key before creating a new one.

Revoke vs delete

These are two distinct actions, and both exist in the dashboard:

ActionWhat it doesReversible
RevokeMarks the key as inactive. It stops authenticating requests immediately. The record stays in the list, visible but unusable.Only by support — there's no "reactivate" button in the dashboard.
DeleteRemoves the key record entirely.No — it's permanent.

Immediate effect

Both revoking and deleting cut access instantly: any request using that key afterward starts failing (see Authentication for the real error shape).

Rotation

There is no "regenerate" button that swaps a key's value while keeping its identity. For user keys, rotation is a manual process:

1

Create a new API key

With the same scopes as the one you're replacing.

2

Deploy the new credential

Update the environment variable on every server or function that consumes the API.

3

Revoke the old one

Once you've confirmed all traffic is using the new key.

Who can manage API keys

Today, only the tenant's owner(s) can create, list, revoke, or delete API keys. A user with an admin or manager role — even one with broad permissions like settings:* — does not have access to this management: the operation requires the owner privilege internally. If your team expects to delegate this to an "Admin" role that isn't the account owner, that's not possible today.

Best practices

  • Apply the principle of least privilege when choosing scopes: don't use the all-resources wildcard for an integration that only needs to read orders.
  • Never embed the key in client-side code, public repositories, or logs.
  • Use environment variables or a secrets manager — never hardcode it into your source code.
  • Since there's no automatic rotation, schedule periodic manual rotations (create → migrate traffic → revoke the old one).
  • If you suspect a leak, revoke the key immediately — don't wait to confirm abuse.

Tip

If your integration needs different access levels (say, one process that only reads orders and another that also updates them), create one key per use case instead of a single key with every permission.

Next steps