Skip to main content
White Label is currently in limited access. Contact ryan.powell@zapier.com to learn more.

​
White label

Zapier White Label lets you use Zapier under your own brand, without end users needing their own Zapier accounts or a direct relationship with Zapier. White Label supports multiple product surfaces. Depending on your use case, your end users can:
  • Embedded triggers/actions: connect an app account and run actions/triggers via API
  • AI agent connections & automations: connect an app account and call tools via Zapier MCP and Zapier SDK
  • Embedded workflows: create and manage Zapier-owned trigger→action workflows via the Workflow API
Zapier handles third-party authentication and action execution; you control the UX, orchestration, and business logic.

​
Where Zapier branding shows up (and what you can control)

There are a few “surfaces” where Zapier branding is visible during authentication:
  1. Connect UI (Zapier-hosted)
    • What users see: the hosted connect flow where they sign in to the third-party app and grant access
    • What you control: the UI can be customized to match your design system so it feels native inside your product
    Example of a customized Connect UI Example: the Connect UI can be styled to match your product branding (colors, typography, layout) while Zapier handles the underlying authentication flow.
  2. Third-party OAuth consent screens (Google, Slack, etc.)
    • What users see: the consent screen from the third-party app
    • What’s important: the consent screen will show that Zapier is requesting access to the user’s third-party app account
    Example of a third-party OAuth consent screen Example: this screen is owned by the third-party app (not Zapier/you), so branding and wording are not fully controllable.

​
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). In practice, most integrations will request both token types (typically via two token exchange requests):
  • Always request an access token for server-side API calls.
  • Request a session code when you need to send the end user through Connect UI to create (or refresh) a connection (often the common path for first-time users).

​
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 UI (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.
For full implementation details (including example code, reconnecting, and detecting popup-close), see Connection flow. 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.