Agiled Docs

API keys let trusted external systems call the Agiled public API.

Create keys for backend systems, not browsers. A public API key should be treated like a password.

Only create a key when there is a real integration owner and a secure place to store it. Keys without owners become security and maintenance risk.

Create a separate key for each integration so you can rotate or revoke one system without breaking every external connection.

Create An API Key

Open Settings.
Go to API.
Enter a key name.
Choose a preset, such as full access or read only.
Select Create key.
Copy the token immediately.

The token is only shown once. Store it in a secure password manager or server secret store.

Name the key after the system and environment, such as "Zapier production" or "Reporting staging", so future admins know what it controls.

Before creating a full-access key, confirm the external system truly needs to write data. Reporting, search, backup, and dashboard systems often need read access only.

Revoke A Key

Open Settings.
Go to API.
Find the key.
Select Revoke.
Confirm the action.

Revoking a key stops systems that use it from making new API requests.

Before revoking, identify the jobs, scripts, or integrations that use the key. Rotate to a new key first when downtime would affect customers or operations.

If you cannot identify a key owner, treat the key as risky. Create a replacement with a clear owner, migrate known systems, then revoke the unclear key after a controlled check.

Rotation Workflow

Create a replacement key.
Update the external system.
Test /public/v1/me.
Test one safe read or write.
Revoke the old key.

Document the rotation date, owner, and external system after the replacement is working. This makes the next security review faster.

Security Guidance

Create separate keys for separate systems.
Use read-only keys when the integration only needs to read data.
Revoke keys when vendors, employees, or automation jobs no longer need them.
Never place API keys in frontend code.

Review keys regularly. Revoke unknown, unused, or overly broad keys and replace full-access keys with narrower access when possible.

Audit Checklist

During a security review:

Confirm each key has a clear name and owner.
Confirm the external system still exists.
Confirm the access level is still needed.
Rotate old or exposed keys.
Revoke keys for retired vendors, scripts, or teammates.
Check that tokens are not stored in frontend code or shared documents.

Troubleshooting

If an integration stops working after revocation, restore it with a new key and then review why the dependency was not documented.

If you are unsure what a key does, create a replacement with a clearer name before deleting anything.

If a key is exposed in chat, email, logs, frontend code, or a shared document, revoke it immediately and create a new key. Do not wait to see whether it is used.

Keep a private inventory of which system uses each key, who owns it, when it was created, and how to rotate it. The key name inside Agiled should be specific enough that an admin can identify it during an incident or offboarding review.

If no one can explain a key, replace it with a clearly named key before revoking the old one so you can observe whether anything still depends on it.

Create And Revoke API Keys