> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zapier.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Partner onboarding

> What you configure with Zapier to launch White Label (JWKS, callbacks, JWT expectations, and client credentials).

# Partner onboarding

<Note>
  White Label is currently in limited access. Contact [ryan.powell@zapier.com](mailto:ryan.powell@zapier.com) to learn more.
</Note>

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 UI 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 UI 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:

```json theme={null}
{
  "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 UI 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:

```text theme={null}
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:

```json theme={null}
{ "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):

| Concept             | Example claim | Example value   |
| ------------------- | ------------- | --------------- |
| user id             | `sub`         | `user_123`      |
| tenant/workspace id | `tenant_id`   | `workspace_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:

```text theme={null}
POST https://zapier.com/oauth/token
```

Next: see [Token exchange](./token-exchange) (get an access token, then exchange it for a connect token when you need Connect UI), then [Connection flow](./connection-flow) (popup vs redirect, reconnecting, and callback parameters).