Skip to main content
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 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

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

​
What you can call

Authentication

Client credentials, JWT claims, scopes, rotation, and rate limits.

Users and consent

Pre-create by email, distribute the claim link, and read the five consent scopes.

Reading user data

Verification status, wallets, USD receiving account, and the personal ledger.

Payouts

Batch treasury transfers, idempotency, caps, and replay semantics.

Webhooks

Signed delivery, verification, retries, and grant-bound cancellation.

Errors

Every code the API returns and what to do about it.

​
Endpoints at a glance

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, then follow the end-to-end recipe in Bring payments into your app.