Delegated access to Zev products
Delegated access to Zev products
Let your app act inside a Zev product, such as ZevCloud, for one user, with their consent, only on the teams or projects they pick.
Delegated access lets your app act inside a Zev product for one of its users. A deployment tool can deploy to a person’s ZevCloud team, for example. The person consents on ZevID and picks which of their teams your app may touch, and can disconnect it at any time.
You connect through ZevAuth, with the keys you already have. ZevAuth relays to ZevID for you, so you never hold a ZevID credential.
How it fits together
- Your app sends the user’s browser to ZevAuth’s authorize entry.
- ZevID signs the user in, shows what your app is asking for, and lets them pick targets: the teams or projects your app may act on.
- ZevID sends the user back to your
redirect_uriwith a one-timecode. - Your server exchanges the code at ZevAuth for an access token (10 minutes) and a refresh token.
- Your server calls the product’s API with the access token.
The product decides what each permission allows and which header names the target. That lives in the product’s own partner guide; see Scopes by product.
Which Zev feature is this?
Four features sound alike. Pick the right one before you write code.
| You want to | Use |
|---|---|
| Let people sign in to your app with their ZevID account | Sign in with ZevID |
| Act inside a Zev product for a user, on targets they picked | Delegated access (this guide) |
| Tell Zev that a member is a verified student, professional or builder | Member attestation |
| Authenticate your own users | The rest of ZevAuth |
Sign in with ZevID proves who someone is. It never lets your app act in a Zev product. A delegated-access token never proves that someone is signed in to your app. Keep the two separate, even when the same person does both.
Who can use it
To test, nothing but your test environment: no approval, no verification, but only your own team can connect it. Start there; see Test environments.
To take real users, your live app needs all of these:
- Live environment.
- Verified domain. Your project’s domain is proved under Go live in the console. Callbacks must be on it.
- Approved per product. Each app is reviewed and approved for each product separately, along with the permissions it may request. See Getting approved.
What the user stays in control of
- They see your app’s name and logo, each permission in plain words, and which of their targets they are giving you.
- High-risk permissions, such as deleting a service, are opt-in, need a recent sign-in, and expire unless the user confirms them again. See High-risk permissions.
- They can remove a target or disconnect your app at any time from Apps and websites in their ZevID account. See Revocation.
Endpoints at a glance
| Endpoint | Key | Purpose |
|---|---|---|
GET /v1/partner/delegated/authorize | Publishable (pk_…) | Browser entry: start or change a connection |
POST /v1/partner/delegated/token | Secret (sk_…) | Exchange a code, or refresh |
POST /v1/partner/delegated/revoke | Secret (sk_…) | Disconnect a connection |
All three live on https://api.zevauth.net, and take live or test keys.
Delegated-access events arrive on your existing
webhook endpoints.
Building it? Read Common scenarios first: it answers most of the questions partners ask.
Updated at, Wednesday, October 21, 2026