Go live

The activation sequence for a partner treasury: credentials, entity and mandate, binding, funding, consent, webhooks, a live canary batch, then activation.

Activation is deliberately ordered. Each step depends on the one before it, and Glide activates the treasury last, after the money path has been proven end to end with real funds.

Steps marked Glide are operator actions. Ask Glide to perform them. Steps marked You are yours.

1. Get authenticated

Glide creates your partner record and returns client_id and client_secret once. Glide enables the treasury:write token entitlement for your client, leaving the five consent scopes unchanged.

You mint a token and verify it works against a read endpoint. Confirm the returned scope string contains what you expect.

2. Settle the legal and funding shape

Glide and you confirm the custody and redemption mandate, then identify the funded reserve account and what will count as settlement evidence.

You create the actual business entity through the normal owner flow, with its real verification status. Binding does not create a business, approve it, or supply funds.

3. Bind the treasury

Glide binds your partner to the entity, the entity-scoped USD balance, your external payer UUID and the reserve account, and sets the caps and mandate expiry you approved.

Binding identity and reserve provenance are immutable once set. The balance is created empty, in disabled status. Existing non-zero funds are never silently adopted.

You record the payer UUID in your configuration. Your client should refuse to send a batch whose payer_entity_id differs from it, so a misconfiguration fails locally instead of at Glide.

4. Fund and record it

You settle real USD into the bound reserve account.

Glide inspects the settlement evidence and records the funding, which credits the USD balance and writes an immutable receipt. Funding is an operator attestation of already-settled money, not a deposit API.

Funds are never moved into the treasury from another spendable Glide account as if they were external funding, and personal receiving details are never treasury funding instructions. Corrections require an explicit accounting operation, because funding receipts cannot be edited.

5. Onboard users and collect consent

You pre-create each recipient by email and distribute the claim link.

Users sign in with that email, claim the account, and approve the scopes. To be paid, a user needs both payouts:receive and transfers:read, plus an active account.

You confirm readiness by reading each user back before including them in a batch. A 404 means no receipt or grant, and a 403 grant_required means the consent is missing or too narrow.

6. Wire up webhooks

Glide adds your exact URL to the allowlist, configures the endpoint and returns its secret once.

You deploy the receiver and validate it end to end: signature verification over the raw body, a five minute timestamp tolerance, deduplication by event id, and a 2xx only after durable acceptance. Confirm you can accept a repeat of the same event without double-applying it.

A configured, allowlisted endpoint is what makes transfer.settled reach you. Without it the payouts still work, and you find out about them only by polling.

7. Prove the whole path

Before activation, prove all of this in the configured environment with real money:

• A funded reserve you can reconcile.
• A small live batch, two recipients is enough.
• The credit visible in each user’s personal Glide USD balance.
• A signed transfer.settled received and correlated on transfer_id.
• A user-authorized bank withdrawal completing from that balance.

Unit tests do not substitute for this. The verification provider, the key management path and webhook delivery only exercise properly in a configured environment.

8. Activate

Glide sets the treasury to active. Activation requires a valid active binding, a future mandate, an active partner and verified funding.

Running it

Monitor continuously:

Watch	Why
Batch receipts and per-item results	Confirms what actually moved
Request and activity audits	Every call is audited with a request id
Rolling and lifetime usage against caps	A cap hit surfaces as policy_denied with no remaining-allowance hint
Webhook delivery and attempt history	Eight attempts, then the event stops being retried
Reserve reconciliation	Reconcile against liabilities already credited to users, not just funds still in the treasury

Keep actual cash-out liquidity. A credited user balance is a liability you have to be able to fund when the user withdraws.

Stopping

Two switches with different blast radii:

Ask Glide to	Effect
Suspend the treasury	Stops new payouts. Reads and webhook delivery keep working, and an authorized replay still resolves
Suspend the partner	Stops all API access and all webhook delivery immediately
Rotate the client secret	Old secret stops minting immediately. Already-issued tokens stay valid for up to an hour

Use treasury suspension for a money problem, and partner suspension for a credential or trust problem. If a secret leaked, do both: rotate and suspend, because rotation alone leaves live tokens valid until they expire.

Pre-launch checklist

• Token cached in process and refreshed before expiry, with a single retry on invalid_token.
• Client secret stored in a secret manager, never in source or logs.
• payer_entity_id pinned in configuration and checked before every batch.
• execution_id and payout_id generated once per obligation and persisted before the call.
• The same Idempotency-Key reused verbatim on every retry of a batch.
• Unconfirmed outcomes retried, never marked failed.
• Webhook signature verified over the raw body with a constant-time compare.
• Webhook events deduplicated by event id before side effects.
• Transfer polling overlaps its watermark and dedupes on id and updated timestamp.
• amount_cents parsed as an integer or decimal type, never a float.
• request_id logged from every error response.