Skip to main content

Partner onboarding

White Label is currently in limited access. Contact ryan.powell@zapier.com to learn more.
Partner onboarding is the first step to setting up White Label. You’ll configure how Zapier should authenticate and identify your users (and their tenant/workspace) via partner-signed JWTs, so Zapier can issue tokens and support Connect without your users needing to manage Zapier accounts directly.

Onboarding checklist

If you run multiple environments (staging + prod), expect to provide separate values per environment (especially callback URLs and client credentials).

What you provide Zapier

  • JWKS URL: where Zapier can fetch public keys to validate your JWT signatures
  • Redirect/callback URL(s): where Connect redirects the browser after the user finishes connecting
  • JWT expectations: expected iss (issuer) and aud (audience) values
  • Claim mapping: which JWT claim contains your user id and which contains your tenant/workspace id

What Zapier provides you

  • Client credentials (client_id, client_secret) for token exchange

Details and examples

JWKS URL

Zapier uses your JWKS endpoint to verify the signature on the partner-signed JWT you send during token exchange. Practical requirements:
  • Public + reliable: Zapier must be able to fetch it server-to-server at runtime.
  • HTTPS: serve over TLS.
  • Supports rotation: publish multiple keys during key rotation and use kid in your JWT header.
Example JWKS response:
{
  "keys": [
    {
      "kty": "RSA",
      "kid": "key-2026-03",
      "use": "sig",
      "alg": "RS256",
      "n": "...",
      "e": "AQAB"
    }
  ]
}

Redirect/callback URL(s)

Callback URLs are used for the redirect connection pattern (Connect sends the browser back to your app with the result in query parameters). Even if you primarily use the popup + postMessage pattern, teams often still register callback URLs for fallback/testing. Example callback URL:
https://your-app.com/zapier/callback

JWT expectations (iss, aud)

Zapier validates standard JWT fields in addition to signature:
  • iss (issuer): identifies your backend as the issuer
  • aud (audience): identifies Zapier as the intended recipient
Zapier will also expect an expiration (exp). Keep expirations short (minutes, not days). Example JWT header:
{ "alg": "RS256", "typ": "JWT", "kid": "key-2026-03" }

Claim mapping (user id + tenant/workspace id)

White Label is multi-tenant by design. Zapier needs to know which JWT claims represent:
  • your user id (the end user in your system)
  • your tenant/workspace id (the workspace/account/org the user belongs to)
Example mapping (your actual claim names may differ):
ConceptExample claimExample value
user idsubuser_123
tenant/workspace idtenant_idworkspace_456

What Zapier provides (client credentials)

Zapier issues a client_id and client_secret that your backend uses during token exchange. Keep these server-side and treat client_secret like a password. You’ll use them when calling:
POST https://zapier.com/oauth/token
Next: see Token exchange (requesting an access token vs a session code), then Connection flow (popup vs redirect, reconnecting, and callback parameters).