> ## Documentation Index
> Fetch the complete documentation index at: https://glide-9da73dea.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.

<Warning>
  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.
</Warning>

## 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.