Skip to main content
Zapier White Label lets you embed app connections and Zapier-powered actions directly inside your product. Your end users can:
  • choose an app
  • connect their account (OAuth/consent)
  • run actions from your UI
Zapier handles third-party authentication and action execution; you control the UX, orchestration, and business logic.

Key concepts

  • Partner-signed JWT: your backend’s signed assertion of “this is user X in tenant/workspace Y”.
  • JWKS URL: a public endpoint where Zapier fetches your public keys to verify JWT signatures.
  • Access token (Bearer): used server-side to call Zapier APIs (list connections, run actions, poll results).
  • Session code: short-lived token used client-side to open the Connect UI.
  • Connection identifier: durable ID returned after Connect completes; you store it and use it to run actions later.

One-time partner onboarding (configuration)

You provide Zapier:
  • JWKS URL: where Zapier can fetch 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
Zapier provides you:
  • Client credentials (client_id, client_secret) for token exchange

Runtime flow (end-to-end)

1) Token exchange (server-to-server)

Your backend exchanges a partner-signed JWT for Zapier token(s) at: POST https://zapier.com/oauth/token Which token you receive depends on request parameters (notably requested_token_type and scope). Commonly, you will request:
  • an access token for server-side API calls
  • a session code when you need to open the Connect UI

2) App selection + check existing connections (server-side)

After the end user selects an app in your UI, your backend uses the access token to:
  • list the user’s existing connections (filtering to the selected app)
  • reuse an existing valid connection when possible
If no valid connection exists, create a new one via Connect (next step).

3) Create a new connection (Connect UI)

To connect (or reconnect) an app, exchange the JWT for a session code, then open the Connect UI. There are two user experience patterns:
  • Popup + postMessage: open Connect in a popup; on success, receive the connection identifier via postMessage.
  • Redirect: redirect the user’s current window to Connect with a redirect_uri; on success, Zapier redirects back to your callback URL with the connection identifier in the query string.
Store the connection identifier in your system mapped to (user, tenant/workspace, app).

4) Run actions (server-side)

Once you have:
  • an access token, and
  • a connection identifier for the app account
…your backend can:
  • list available actions and fetch their input fields
  • create an action run
  • poll for completion
  • return results to your UI
See Running actions: Getting Started for details.

Operational notes

  • JWKS reliability matters: if your JWKS endpoint is down, JWT verification fails and token exchange fails.
  • Key rotation: publish multiple keys during rotation; use kid to select keys cleanly.
  • Keep secrets server-side: do not expose client_secret or access tokens in the browser.