Skip to main content
Each agent identity has its own signing key, used to verify the webhooks and WebSocket upgrades for that identity’s mailbox, phone number, and iMessage traffic. Verify incoming payloads for an identity’s mail and phone channels with that identity’s key. Until an identity has a key, its webhooks and WebSocket connections are sent unsigned. Once a key exists, all of that identity’s webhooks and WebSocket upgrades are signed automatically. The plaintext key is returned only once when created or rotated. Store it securely — it cannot be retrieved again. Your existing webhooks continue to verify with the same secret. Signing keys are complementary to a subscription’s optional delivery auth_token: the signature is per identity and proves a payload came from Inkbox unmodified, while the bearer token is per subscription and authenticates Inkbox to endpoints that require an Authorization header. Setting one does not affect the other.

How an identity first gets its key

A brand-new agent identity has no signing key. There are two ways one comes into existence:
  • Automatically, on the first subscription. The first webhook subscription you create for a keyless identity returns that identity’s signing secret once, in the signing_key field of the create response. Store it then — it isn’t shown again. See Subscriptions.
  • Explicitly, via the POST route below. Call POST /identities/{agent_handle}/signing-key to mint a key up front (or to rotate an existing one).

Get signing key status

Report whether this agent identity has a signing key configured. Does not return the secret.

Response (200)

JSON

Code examples


Create or rotate signing key

Create a signing key for this agent identity, or rotate the existing one. On the first call a new key is generated. On subsequent calls the old key is replaced with a fresh one.

Response (201)

JSON

Error responses

Code examples


Deprecated: org-level signing key

The org-level endpoints POST /signing-keys and GET /signing-keys are deprecated. Their responses carry a Link header pointing at the per-identity route above. Move to …/identities/{agent_handle}/signing-key. While they remain available, behavior depends on the caller’s auth scope:

Verifying webhook signatures

Once you have an identity’s signing key, use it to verify incoming webhook payloads for that identity. See: