Configure console integrations

Open Console Integrations to create credentials, register browser origins, or configure signed webhook delivery. Confirm the workspace identity and environment in the sidebar first. An administrator or owner can manage these settings. Store issued secrets on your backend.

Create a credential

The credentials list is filtered by the selected environment: sandbox corresponds to test-mode credentials. Give each credential a name that identifies its application and use. Select the minimum supported scope.

The browser SDK receives a short-lived token minted by your backend with its server or admin credential. Authenticate the user at your token endpoint, resolve the subject from server-side account data, and bind the token to the intended origin. Keep the Console-issued secret off the browser.

Plaintext credential material is shown once. Copy it directly into an appropriate secret-management workflow, verify the integration, and close the display. Do not put it in a URL, client bundle, documentation example, or screenshot. See authentication reference for accepted credential types.

Revoke and rotate deliberately

Revoking a credential retires that credential's access. Check dependent services before revocation and validate that the intended replacement is working. Emergency exposure may require immediate revocation followed by incident review.

The console's Rotate signing secret control concerns HMAC authorization-token signing. Rotation invalidates outstanding HMAC authorization tokens for the tenant, including tokens minted through other credentials. Manage API credentials and browser client tokens through their respective lifecycle controls. Use proof or subject revocation to invalidate ES256 Proofs of Agency.

The different credentials and signing mechanisms protect different boundaries. Follow the credential replacement and proof lifecycle procedures appropriate to the incident.

Register exact browser origins

An origin includes scheme, host, and non-default port; it does not include a path. Register the exact application origin that will collect evidence. For example, https://merchant.example and https://admin.merchant.example are different origins, and an explicit local development port is distinct from another port.

Origins are shared across the tenant. Removing an origin may affect more than the environment currently selected in the console. Inventory applications before changing the list. Production collection requires the allowed secure application origin; follow the quickstart for the supported localhost development arrangement.

Authenticate the application session on your backend before issuing a subject-bound token for the registered origin. Keep the server credential in the backend secret store.

Add a webhook destination

Configure a public HTTPS receiver you control, choose the event subscriptions it needs, and select whether it receives sandbox, live, or both environments. The page lists tenant destinations with their event environment. Use separate receivers or explicit environment checks when that helps isolate development from production processing.

Copy the one-time webhook signing secret to the receiver's secret store. Implement raw-body V2 signature verification, all required signature headers, timestamp tolerance, and durable event deduplication before acting on events. The webhook guide includes the exact verification contract.

Choose Send test event, then check that your receiver accepted the signature and stored the event. If it fails, inspect delivery errors before retrying. Treat test events as diagnostics in the receiver so they cannot trigger business effects.

Inspect delivery and recover failures

Deliveries in flight shows queued work, attempt count, next attempt, and the latest error. Successfully delivered events leave that list. A delivery that exhausts its retries is parked in Dead letters, where permitted operators can replay or discard it.

Before replaying, fix the receiving endpoint and check whether the event already produced an effect. A timeout may occur after your receiver committed its work. Replays therefore require the same durable idempotency handling as ordinary duplicate deliveries.

Replays are audited and signed with the current webhook secret. After a secret rotation, deploy the expected verification configuration before replaying old events. Account for the supported overlap/rotation behavior without accepting unsigned or stale requests.

Discarding a dead letter records the decision to stop that delivery attempt; it does not undo customer-side work. Preserve the event reference and reason in your operational process when the event matters to an investigation.

Reconcile important activity

A recorded event can lack a queued delivery, and deliveries can arrive repeatedly or out of order. Reconcile important asynchronous workflows against authenticated activity records. The webhook guide covers deduplication, freshness, and receiver recovery. Continue using synchronous authorization and proof verification for protected execution.