Authentication and authorization
Four separate questions Ryde answers separately: who is calling, what they may do, whether the customer may transact, and whether this purchase is authorized.
These four are independent. An API key is not a membership; a membership is not a purchase authorization; OAuth consent is not a standing licence to spend. Keeping them separate is what makes it safe to let software transact on someone's behalf at all.
| Layer | Question it answers | Set by |
|---|---|---|
| Authentication | Which application is calling, and for which Ryde customer? | OAuth authorization code + PKCE |
| Authorization | Which capabilities did that customer approve? | Scopes on the access token |
| Entitlement | May this customer transact through an external agent at all? | Ryde One membership / Ryde One Business Agreement |
| Confirmation | Is THIS particular purchase authorized, right now? | A fresh quote the customer was shown, plus an idempotency key |
The authorization scenarios
User-delegated OAuth
Your application acts for a Ryde customer who approved it. This is how every consumer integration works, including AI assistants. The customer's credentials never reach you.
Merchant authorization
Your application acts for an approved merchant or service provider — a POS, a restaurant's own automation, a property-management platform. It additionally requires an active Ryde One Business Agreement held by that merchant. COMING SOON.
MCP authorization
An AI client obtains a scoped user token by the same OAuth flow, discovered through protected-resource metadata. There is no separate MCP credential and no MCP bypass.
Application-only authentication
Not offered. Every operation in the Agent Network acts for a specific Ryde customer or merchant, so every call carries a token that names one. There is no credential that lets an application act on the marketplace as itself — that is the design that stops one integration proxying many people.
Never send a Ryde access token to any host other than Ryde's, and never pass one to a downstream service or model provider. A token names a specific customer and a specific application; anywhere else it is only a liability.