Programmable keys explained
How Programmable Keys Control API Access
A programmable key is an API credential created and managed through rules you can audit. This guide follows a key from creation to rotation and revocation.
Written for teams who share integrations across staff and vendors. Short read, practical steps, no sales pressure.
Lifecycle on this page — create, scope, store, log, rotate, revoke, review
If you manage one integration or twenty, the same path applies. Start with ownership, keep scopes narrow, and keep a written record you can check later.
Start with intent
What Makes a Key Programmable
Managed access means you can answer three questions for any key: who owns it, what it may touch, and when it ends.
Metadata rides with the secret
A programmable key carries owner, purpose, scope, expiry, and environment. You create it through an admin tool or API, not by pasting a secret into chat. Because creation is recorded, you can list every active key later and know why each one exists.
That record is the difference between managed access and a drawer full of mystery tokens. Teams in multi-service setups depend on that list during staff changes, when someone leaves or a contractor wraps up and you need a clean handoff.
Creation With Clear Ownership
Start each key with four fields: human owner, system purpose, allowed endpoints, and expiry date. Use names like billing-sync-prod-read or vendor-trial-sf-dec2026 so future readers understand intent.
Tie test keys to a short window, often days rather than months. Production keys get longer windows but still expire. If no one can name the owner, do not create the key. A short intake note — who asked, what system calls what — saves hours when you clean up in a quarter.
Scopes That Limit Damage
Scopes define what a key can do and where. Prefer narrow verbs: read invoices, write shipment updates, no user deletion. Separate environments completely so a staging key cannot call production.
For vendor trials, issue a key that touches one sandbox endpoint with sample data. Narrow key scopes and permissions keep a leaked key from becoming a broad incident. Review scopes whenever a feature adds a new endpoint, and shrink anything that grew wider than its job.
Bench detail — cartridges, vault, runtime load
Handling rules
Storage Teams Can Defend
Never store keys in code repos, screenshots, or shared docs. Keep production secrets in a vault or managed secret store with access logs.
Applications should load keys at runtime from environment configuration. Developers keep only test keys on laptops. One blunt rule helps: if a key appears in email, rotate it and move it to the vault.
Traceable by design
Logging Without Leaking Secrets
Log the key ID, timestamp, endpoint, result code, and bytes transferred. Do not log the secret value itself.
Hash or truncate IDs in a consistent way so you can trace use without exposing credentials. Keep logs long enough to cover a billing cycle or a monthly sync dispute. Short retention hides the evidence you need when a partner asks what happened last month.
Scheduled replacement
Rotation on a Schedule
Rotation replaces a working key with a new one before risk builds. Create the new key, deploy it alongside the old one, confirm traffic shifts, then disable the old key.
High-risk write keys rotate more often than low-risk read keys. Put the next date on a shared calendar with an owner. Teams that skip this step usually discover stale keys only after an incident.
Grace window that catches stragglers
Short grace periods, often 24 to 72 hours for internal services, give you time to catch missed workers or cron jobs. Longer windows suit external vendors across time zones. Watch both keys during the overlap, then close the old lane.
Immediate shutdown
Revocation When Something Looks Wrong
Revocation is immediate shutdown. Keep a one-page runbook: where to revoke, who approves, how to notify affected users, and what replacement key to issue.
If a key shows odd volume at 2 a.m. from an unusual client, revoke it first and review logs after. Record the time, reason, and replacement ID. That note shortens post-incident meetings and keeps support answers consistent.
- Revoke in the issuing tool, confirm the key stops returning success codes.
- Issue a scoped replacement through the vault and update runtime configuration.
- File time, reason, and replacement reference where on-call and support can find it.
Quarterly habit
Key Reviews for Busy Teams
Run a quarterly access review. List active keys, owners, scopes, and last used dates. Remove unused keys and tighten overbroad scopes.
Confirm that former staff and finished vendors no longer hold active credentials. A 30-minute review with engineering and product present catches most drift. File the result where auditors or managers can find it later, with dates and initials attached.
What to bring
Export of active keys with owner, scope, expiry, and last used date. Flag anything idle past one cycle.
What to decide
Keep, tighten, rotate now, or remove. Assign each decision before you leave the room.
Review table — what a clean row looks like
Name states purpose and environment, owner is a person, expiry is a real date, last used is recent or the key is gone.
Example — billing-sync-prod-read, current, in use
Trial and vendor keys
Live days, not months. One sandbox endpoint, sample data, clear end date.
Internal read keys
May live longer with regular review. Narrow verbs, monitored use, known owner.
Broad write keys
Short-lived and rotated on schedule. No shared write key across vendors.
Common questions
Answers teams ask before they issue keys
Should each vendor get its own key?
Yes, in most cases. Separate keys let you set different scopes and expiry, and let you revoke one vendor without breaking other integrations. Shared keys turn a small offboarding into a broad outage risk.
How long should a key live?
Match lifetime to risk. Short trial keys may live days. Internal read keys may live longer with regular review. Any key with broad write access should be short-lived and rotated on schedule, with the next date owned on a shared calendar.
What if a key leaked in chat or email?
Revoke it, issue a replacement through your vault, and check logs for the exposure window. Then remove the secret from the message history if your tool allows it. Treat any appearance in email as a rotation trigger, not a cleanup task for later.
Keep going
Put this lifecycle to work on your next integration
Walk through movement patterns with the handbook, check readiness with the list, or write to our Stanford team about key scopes for your stack.
Applithic — 450 Serra Mall, Stanford, CA 94305, USA — +1-650-723-2300 — [email protected] — Monday–Friday: 9:00 AM – 6:00 PM