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

# Partner API

> Pay your users through Glide. Pre-create accounts by email, read consented KYC and wallet state, receive signed webhooks, and push batch payouts from a prefunded treasury.

The Partner API lets an external platform put money in its users' hands through Glide. You pre-create a Glide account for each of your users by email, the user consents to exactly what you may see, and you push USD payouts to them from a prefunded Glide treasury that Glide binds to your business entity.

Base URL for every call is `https://glide.co`.

## Who this is for

A creator marketplace, a payroll product, a freelance platform, or any business that owes money to a list of people and does not want to build banking. You keep the relationship and the obligation. Glide provides the account interface, wallet integration, identity verification flow, USD receiving details and ledger. Regulated services are provided by licensed partners.

If you are building an AI agent that spends from your own Glide account, you want [Agent banking](/agents/index) instead. The Partner API is about paying other people.

## The model

Glide owns the user. Partner pre-creation does not create a wallet, provision a bank account, perform identity verification, or grant you access to anything. Those resources appear as the user completes the normal Glide flows, and you see them only after the user grants you consent.

Three things have to line up before you can read a user's data or pay them:

1. **Your token entitlements.** Glide records which scopes your client may ever request. Your access token carries a subset of them.
2. **The user's grant.** The user approves a specific set of scopes for your partner on a Glide consent screen. Grants are read fresh on every request and every webhook attempt.
3. **The user's account status.** The user must be active.

Missing any of the three fails closed. Consent is personal and never exposes business-entity data.

## How the money moves

```
your treasury USD balance  ->  user's personal Glide USD balance  ->  user withdraws
   (prefunded, capped)          (synchronous, atomic book transfer)     (USD to USDC, then bank)
```

A batch payout is a synchronous, atomic USD book transfer inside Glide. Settlement means spendable personal Glide USD credit. It does not mean a bank withdrawal or an on-chain transfer. The user then chooses when to convert and cash out, using Glide's own flows.

<Note>
  Receiving a payout does not require the user to be identity verified. Converting USD to USDC on the way to a bank withdrawal does require approved verification. A user can hold a Glide USD balance long before they finish verification.
</Note>

## What you can call

<CardGroup cols={2}>
  <Card title="Authentication" icon="key" href="/partners/authentication">
    Client credentials, JWT claims, scopes, rotation, and rate limits.
  </Card>

  <Card title="Users and consent" icon="user-check" href="/partners/users-and-consent">
    Pre-create by email, distribute the claim link, and read the five consent scopes.
  </Card>

  <Card title="Reading user data" icon="table-list" href="/partners/reading-user-data">
    Verification status, wallets, USD receiving account, and the personal ledger.
  </Card>

  <Card title="Payouts" icon="money-bill-transfer" href="/partners/payouts">
    Batch treasury transfers, idempotency, caps, and replay semantics.
  </Card>

  <Card title="Webhooks" icon="satellite-dish" href="/partners/webhooks">
    Signed delivery, verification, retries, and grant-bound cancellation.
  </Card>

  <Card title="Errors" icon="triangle-exclamation" href="/partners/errors">
    Every code the API returns and what to do about it.
  </Card>
</CardGroup>

## Endpoints at a glance

| Method | Path                                    | Scope                 | Limit   |
| ------ | --------------------------------------- | --------------------- | ------- |
| POST   | `/api/partner/oauth/token`              | client credentials    | 30/min  |
| POST   | `/api/partner/users`                    | authenticated partner | 60/min  |
| GET    | `/api/partner/users/:id/kyc`            | `kyc:read`            | 300/min |
| GET    | `/api/partner/users/:id/wallets`        | `wallet:read`         | 300/min |
| GET    | `/api/partner/users/:id/us-account`     | `us_account:read`     | 300/min |
| GET    | `/api/partner/users/:id/transfers`      | `transfers:read`      | 300/min |
| POST   | `/api/partner/kyc/:id/link`             | `kyc:read`            | 10/min  |
| POST   | `/api/partner/treasury/transfers/batch` | `treasury:write`      | 10/min  |

Limits are per partner and per operation, enforced by atomic Postgres counters shared across web workers. A 429 response carries `Retry-After: 60`.

All responses carry `Cache-Control: no-store` and an `X-Request-Id`. Every invocation is audited, including auth and input failures. If audit persistence fails, the request returns 503 rather than disclosing a successful read.

## What you do not get

* No private keys, signing capability, smart accounts or entity vaults.
* No identity documents, rejection reasons, provider tokens or verification blobs.
* No raw provider payloads, beneficiary details, or compliance and risk fields.
* No business-entity data belonging to the user.
* No way to widen a user's consent from the API. Only the user can grant scopes.

## Next

Start with [Authentication](/partners/authentication), then follow the end-to-end recipe in [Bring payments into your app](/cookbook/bring-payments-into-your-app).