Partners and API / Webhooks and API keys
Events out, credentials managed, revocation immediate
Subscribe to platform events, manage the keys that authorize them, and revoke access that stops working the moment you revoke it.
Most credential incidents are not stolen keys. They are keys that outlived the integration, the project or the person who created them.
Audit your keys with usHow fast does a revoked key stop working?
Immediately. Revocation denylists the credential rather than waiting for expiry, which is the same mechanism used for user sessions. A key that has leaked stops being useful at the moment you notice, not at the end of its natural life.
Keys, events, delivery
Managing what you have issued
- 01
Keys are inventoried
Issued keys are visible with what they are scoped to. An integration credential nobody can find is a credential nobody can revoke.
- 02
Revocation is immediate
Denylisted rather than expired. There is no window in which a revoked credential still works.
- 03
Webhooks deliver events
Subscribe to platform events so your systems react to a claim status change rather than polling for it.
- 04
Failed deliveries are visible
A webhook endpoint that stops accepting is surfaced rather than silently dropping events — the failure mode that makes event integration untrustworthy.
- 05
Secrets are never returned
Like every integration credential: once saved, not readable back from any screen or response.
Credential hygiene
The questions an audit will ask about keys
API credentials are where careful access control usually leaks, because they outlive the people and projects that created them.
| Question | Answer |
|---|---|
| What keys exist? | Inventoried with scope and creation record |
| Who created this one, and when? | Audited like any other grant |
| What can it reach? | Its scope — entitlement then role, same as a person |
| How do we kill it? | Revoke; denylisted immediately |
| Can we read the secret again? | No. Write-only once saved |
| Are our webhooks arriving? | Delivery failures are surfaced, not swallowed |
Delivery guarantees, stated plainly
Event delivery is genuinely hard, and vague promises here cause production incidents on your side rather than ours.
Your endpoint must be idempotent
Assume a delivery can arrive more than once. Any event system that promises exactly-once to an arbitrary HTTP endpoint is overselling.
Retries are finite
A persistently failing endpoint stops being retried, and that is surfaced. Silent infinite retry is worse for everyone.
Not a message bus
Webhooks notify. If you need guaranteed ordered streaming into your own infrastructure, that is a different conversation and we will have it honestly.