Users and consent

Pre-create a Glide user by email, send them the claim link, and understand what the five consent scopes let you see.

You bring the email address. Glide creates a placeholder account, hands you a stable user id, and gives you a link that takes the person to a consent screen. Nothing else happens until they sign in and approve.

Pre-create a user

POST https://glide.co/api/partner/users

Requires an authenticated partner token. No user scope is needed, because there is no user yet. This is the one endpoint that does not require a user grant.

Send Content-Type: application/json with a body of at most 4096 bytes. Unknown fields are rejected.

curl

curl --request POST https://glide.co/api/partner/users \
  --header "Authorization: Bearer $GLIDE_ACCESS_TOKEN" \
  --header 'Content-Type: application/json' \
  --data '{ "email": "[e-mail]" }'

Request:

{ "email": "[e-mail]" }

Response:

{
  "user_id": "11111111-1111-4111-8111-111111111111",
  "created": true,
  "claim_link": "https://glide.co/partner/consent?partner=example-market&scopes=kyc%3Aread+wallet%3Aread+us_account%3Aread+transfers%3Aread+payouts%3Areceive"
}

Field	Notes
email	Trimmed and lowercased using Glide’s identity policy. Maximum 254 characters
user_id	UUID. Stable forever, including after the user claims the account
created	Describes the first call for this partner and email. It does not change on replay
claim_link	The consent URL to send the user. Glide sends no email

Repeated pre-creation returns HTTP 200 with the same user_id. A transaction plus the unique email constraint and a per partner and email receipt makes retries stable. If the user already exists on Glide, you get created: false and the existing id.

Another partner can link the same Glide user. The two grants stay independent, and neither partner learns about the other.

Rate limit

60 requests per minute per partner. A 429 carries Retry-After: 60.

Send the claim link

Glide does not email anyone on your behalf. Put the claim_link in your own onboarding email, dashboard banner or in-app card, and tell the user which email address to sign in with.

The claim link is navigation to a consent screen, not a bearer capability and not a login bypass. It carries no email and no user id. It is safe to render in your UI, but it does nothing on its own.

The user must sign in with the email you pre-created. On the first authenticated request from the consent screen, Glide fetches the identity from Privy server-side and atomically attaches the verified Privy id, but only where the account’s email matches and no Privy identity is attached yet.

That compare-and-set has consequences worth stating plainly:

• The Glide user id, your receipt and any grants are preserved through the claim.
• The claim can never replace another Privy identity that is already attached.
• An identity with no email cannot claim an account.
• A user who already has a Glide account continues through normal login.
• Signing in with a different email consents for that other account. It does not claim the pre-created one, and you will keep seeing an unclaimed placeholder.

If a user signs in with the wrong address, pre-create the address they actually used, then send them that claim link.

Account type

Partner placeholders have no account type. After signing in with the verified email and claiming the account, the owner chooses Individual or Company through Glide’s existing one-time type selection. Pre-creation cannot select the type, and it cannot change a type that is already established.

The consent screen

The user lands on https://glide.co/partner/consent, signs in, sees your partner name and the exact permissions you requested, and clicks Allow access.

Approving replaces that user’s scope set for your partner with exactly what they approved. It is a replacement, not a merge. A user who re-consents with fewer scopes has narrowed your access.

Users manage this at Settings then Integrations, where every grant is listed with a Revoke access action. Both personal and business users see it. Consent is personal, and it never exposes business-entity data to you.

The five consent scopes

Scope	What the user sees	What it lets you call
kyc:read	View verification status and request a hosted verification link	GET /users/:id/kyc, POST /kyc/:id/link, and kyc.status_changed events
wallet:read	View your wallet addresses	GET /users/:id/wallets
us_account:read	View your USD receiving account details	GET /users/:id/us-account, and us_account.provisioned events
transfers:read	View your personal transfer history	GET /users/:id/transfers, and transfer.settled and transfer.failed events
payouts:receive	Receive payouts from this partner	Being a recipient in a treasury batch

Request only what you need. The consent screen shows the exact list, so a shorter list converts better.

To pay a user you need both payouts:receive and transfers:read on their grant. payouts:receive alone is not enough, because the payout writes a transfer the user must be able to see.

How access is checked

Grants are read fresh on every user endpoint and every webhook attempt. Both your token scope and the user’s grant must cover the scope the endpoint needs.

Situation	Result
Token scope and user grant both cover the endpoint	200
Relationship exists but consent is absent, revoked or too narrow	403 grant_required
No pre-creation receipt and no grant for your partner	404 user_not_found
User id belongs exclusively to another partner	404 user_not_found
Your partner is suspended	403 partner_inactive
The user is not active	403 user_inactive

A 404 is deliberate. Glide will not confirm that a user id exists on a platform that has no relationship with them.

Consent is never expanded automatically. If you need a scope you do not have, send the user back through the consent screen with the wider scope list.

Revocation

A user can revoke at any time from Settings then Integrations. Revocation takes effect on the next request and the next webhook attempt. Queued webhook events bound to the revoked grant are cancelled, and re-granting does not release events queued under the prior consent.

Revoking access can stop you reading a historical receipt. It does not reverse a payment you already made.