Steerd Help

API keys

Creating a key, choosing what it can reach, expiry, and the one moment you can copy it.

Create and manage access tokens for the API.

A key lets a script, a service or an integration act on your workspace without a browser session. The API itself is documented at docs.steerd.io.

Creating one

Give the key a name, choose its access level, and an optional expiry.

Name it after the thing that will use it, not after yourself. "CI deploy token" tells you what breaks if you revoke it; "Anna's key" does not.

Scopes

Access is per resource: organizations, contacts, employees, projects and the rest. For each, choose none, read, or write.

Write includes read.

Grant the minimum that works. A key that only reads projects cannot damage anything even if it leaks, and most integrations genuinely only read.

At least one scope is required, because a key that can reach nothing is not a key.

Expiry

Optional, and worth setting. A key with an expiry fails loudly on a known date. A key without one lives until somebody remembers it exists, which in practice means forever.

Copy it now

The key is displayed once, at creation. Steerd stores a hash, not the key, so it cannot show it to you again and neither can support. Lose it and you create a new one.

Revoking

Immediate. Anything using that key stops working at once, which is what you want when a key has leaked and is inconvenient when you revoked the wrong one. That is the argument for good names.

Creating and revoking keys is recorded in the audit log.

When a member is removed or disabled

Removing a team member, or disabling one, revokes every key that person created in this team, at the moment you confirm. Their contacts sync passwords go the same way, which Syncing contacts to your phone covers.

It is permanent. Inviting the person back, or enabling them again, restores the membership and leaves the keys revoked, because a key that was valid while somebody had access must not turn valid again on its own once they return.

Two consequences that catch people out:

  • A returning colleague needs a new key, created by an admin, and every script or service using the old one has to be pointed at it. Nothing repoints itself, so the integration keeps failing until somebody edits it.
  • Connected apps count as keys. Authorizing an app through OAuth mints a key in the authorizing person's name, so removing them cuts that app off even if they never created a key by hand. The app has to be authorized again.

Keys created by anybody still in the team are untouched. What was revoked, and why, is in the audit log, which is the quickest way to work out which integration just went quiet.

More on the removal itself: Team, roles and seats.

On this page