Managing API Keys
The API Keys page lets you create, view, and manage the keys your applications use to call the FourA API.
Viewing Your Keys
The page shows every key you have access to: your personal keys, and every key owned by an organization you belong to. Membership is what grants access, so a plain member sees the organization's keys too.
| Column | What it shows |
|---|---|
| Name | Display name and, if you set one, the description |
| Owner | Personal, or the organization's name |
| Key Prefix | Masked prefix (pk_live_••••••••) with a Reveal button, or a lock icon on a legacy key |
| Status | Active or Inactive |
| Created | When the key was created |
| Last Used | When the key last made a request |
Search by name or description, filter to Active or Inactive, and sort by any header. Sort direction cycles descending, ascending, then off.
The Owner Filter
If you belong to at least one organization, an Owner dropdown appears next to the search box: Everything, Personal, or one entry per organization. It narrows the list to keys with that owner, and the same control on Overview, Metrics, Activity, and Proxy follows your choice, so the five pages always agree about whose traffic you're looking at.
Creating a Key
Click Create Key above the list (Create API key on the empty page before your first key) and fill in:
| Field | Required | Description |
|---|---|---|
| Name | Yes | A descriptive label, for example "production-scraper" or "staging-test" |
| Description | No | Notes about what this key is used for |
| Owner | Yes if you're in an organization | Personal, or any organization you belong to. The picker only appears when you have at least one. |
Any member of an organization can create a key it owns, whatever their role. That's the point of the setting: usage on an organization key bills the organization's owner, so a developer doesn't need a personal key that quietly bills them instead of the company.
The full key is shown once right after creation in a copy-ready dialog. You can bring it back later with Reveal. Keys use the pk_live_ prefix and look like pk_live_a1b2c3d4e5f6.... You'll get an email confirming the key was created.
Revealing a Key
Click the eye icon next to a key's masked prefix to see its full secret again. The dashboard asks you to confirm, then opens a dialog with the plain key, a copy button, and a short countdown. After the countdown, the dialog wipes the secret from the page.
Every reveal is recorded in the audit log, because it exposes a live credential.
Anyone the key is shared with can reveal it: its personal owner, or any member of the organization that owns it.
Legacy Keys
Keys created before the reveal feature shipped show a lock icon instead of the eye and can't be revealed. Only their hash was stored, so the original secret is unrecoverable. To switch a legacy key over, open the actions menu and choose Regenerate. The new secret is revealable from then on.
What Each Role May Do
On a personal key you can do everything. On an organization key, three levels apply:
| Action | Member | Admin | Owner |
|---|---|---|---|
| Use the key and reveal it | Yes | Yes | Yes |
| Rename it, edit the description | Yes | Yes | Yes |
| Enable or disable it | No | Yes | Yes |
| Regenerate the secret | No | Yes | Yes |
| Delete it | No | Yes | Yes |
| Move it out of the organization | No | No | Yes |
Disable and Edit stay on the row but are greyed out with a note saying why. Regenerate, Transfer, and Delete don't appear in the menu when your role can't use them. The API refuses the same actions, so an integration can't route around the interface.
The split follows what each action costs the people sharing the key. Renaming is harmless. Regenerating or disabling stops every colleague's integration the instant it happens. Moving a key out takes it away from the company and puts its usage on the taker's own plan, so that one is the owner's alone.
Editing a Key
Click Edit to update the name and description. Ownership isn't changed on this dialog: use Transfer.
View Metrics in the actions menu opens Overview filtered to that key.
Activating and Deactivating
Use Disable or Enable on the row. Deactivating a key blocks every API request that uses it, and you can reactivate it at any time. The change takes effect within seconds.
Regenerating a Key
If you suspect a key has been exposed, open the actions menu and choose Regenerate. This creates a new secret for the same key ID. The old secret stops working immediately. Name, owner, and every other setting stay the same.
The new secret stays revealable after the dialog closes, so you don't have to copy it perfectly on the first try.
Transferring a Key
Transfer in the actions menu moves a key between personal and organization ownership without regenerating the secret. The key ID, its metrics, and its activity history are preserved. Only the owner changes, and with it who the usage bills to.
| Move | Who can do it |
|---|---|
| Personal key into an organization | Anyone who belongs to that organization |
| Organization key out, to yourself | The organization's owner |
| Between two organizations | The owner of the organization the key is leaving |
A key that moves into an organization joins its default "Everyone" team, which is what makes it visible to the members. A key that moves out leaves every team it was in.
Deleting a Key
Open the actions menu and choose Delete. Deleting a key you've used before disables it: the key stops authenticating and stays on the list as Inactive, so its Activity and Metrics history keep its name. Keys that have never been used are removed outright.
You'll get an email when a key is deleted.
Organization Keys and Billing
Usage on an organization-owned key counts against the organization owner's plan, whoever fired the request. The owner's Usage & Limits page counts those keys alongside their personal ones and splits the two.
Related
- Authentication: How API keys work with the API
- Organizations: Roles, members, and shared access
- Usage & Limits: Which keys count against your plan
- Dashboard Overview: All dashboard sections