Manage API keys
Everything here happens in Settings → API keys. You need to be an owner or admin of the workspace.
Create one key per integration
Give each integration its own key, named for what it does: Data warehouse sync, Looker dashboard, Ops alerting.
It costs nothing and it buys you three things. You can see in usage which integration is actually making requests. You can revoke one integration without breaking the others. And each key gets its own rate limit budget, so a runaway backfill in one job cannot throttle another.
The opposite pattern, one shared key pasted into several systems, means that the day you need to revoke it you take down everything at once and you cannot tell what you broke.
Storing keys safely
An API key is a credential with the same weight as a database password.
Do: store it in your deploy platform’s environment variables, a secrets manager, or your CI secret store. Read it at runtime.
Do not: commit it to source control, paste it into a shared document or ticket, log it, put it in a client-side bundle or mobile app, or send it to us in an email or chat message. We will never ask you for the value of a key, and no Asky email will ever contain one.
If a key does reach a public repository, our secret-scanning integration may alert us and we may revoke it proactively to protect your data. You will be notified if that happens.
Expiration
When creating a key you choose 90 days, 1 year (the default), no expiration, or a specific date.
There is no forced expiry, and no regulation requires one. What matters for ISO 27001 and SOC 2 is that you have a documented policy and the ability to rotate and revoke, not that a key dies on a schedule. Forced short expiry mostly produces broken integrations and rushed handling of secrets.
Every creation, roll and revocation is recorded with the acting user and a timestamp, and that record outlives the key itself. Ask us if you need it exported for an access review.
Choose a date when the integration is genuinely temporary, such as a migration or a consultant’s access. Choose no expiration for a long-running production sync, and rely on rolling it when something changes.
If a key does have an expiry, we email the workspace’s owners and admins seven days before and again the day before, whether or not the key has been used recently. A key wired into a quarterly job looks idle and is not, and we would rather send a warning nobody needed than stay quiet on one that mattered. The email includes when the key was last used, so you can tell instantly whether it needs attention or can be left to lapse.
Warnings are service notices about your account, so they are not affected by your email preferences. They stop as soon as the key is revoked or rolled, and they are not sent for workspaces whose plan no longer includes API access, since those keys have already stopped working.
Roll a key
Rolling replaces a key with a new one while keeping the old one alive for a grace period, so you can deploy without downtime. Use it for routine rotation, when someone who had access to the value leaves, or when you are not certain a key stayed private.
Start the roll
Select Roll on the key. Choose how long the current key keeps working:
| Option | Use when |
|---|---|
| Immediately | You believe the key is compromised |
| 1 hour | You deploy quickly and want a short overlap |
| 24 hours (default) | Normal rotation |
| 3 days / 7 days | Deploys go through a slower release process |
The new key keeps the same name, workspace, scopes, and brand restriction, so nothing else about your integration changes.
Copy the new key
It is shown once, exactly as at creation.
Deploy the new value
Replace the old value in your environment variables, secrets manager, or CI secrets, then redeploy or restart anything that caches it.
Verify
curl https://api.askylabs.com/v1/me -H "Authorization: Bearer $NEW_KEY"A 200 with the expected workspace confirms the swap.
Retire the old key early, optionally
During the grace window both keys appear in the list, paired, and the old one shows its live last used time. If it has stopped receiving traffic, you know propagation is complete and you can select Expire now rather than waiting.
Revoke a key
Revoking stops a key working immediately, with no grace period. There is no undo.
Use it when a key is compromised, when an integration is retired, or when the old key from a roll is confirmed idle. If you are rotating a key that is still serving production traffic, roll it instead: revoking first means an outage until you finish deploying.
Reduce what a key can reach
A key’s permissions can be narrowed at any time, but never widened. To give an integration access to something it does not have, create a new key.
That asymmetry is deliberate. Narrowing is a safety action, and it is the fastest way to contain a key that is behaving oddly without taking the integration down entirely. Widening a deployed credential is how a small compromise becomes a large one, so it requires minting a new key and deploying it, which is a deliberate act.
Review your keys
Owners and admins are emailed periodically with a summary of the workspace’s keys, including any that have not been used in 90 days. Unused keys are worth revoking: they are credentials nobody is watching.
The key list shows the last-used time for every key, and can be exported if you need evidence for a security review or audit.
When someone leaves
Because keys belong to the workspace, removing a person from it does not break integrations they set up. That is the intended behaviour, but it does mean their keys need a human decision rather than disappearing on their own.
When a member who created API keys is removed from a workspace, we email the remaining owners and admins with the list to review. If that person had access to the key values, roll those keys.