Skip to main content

​
Embedded workflows

This use case is for products that want end-to-end automations—a trigger plus one or more actions, optional filters, and field mapping between steps—owned and executed by Zapier, while your product owns the UX (discovery, configuration, enable/disable, and surfacing status). This White Label path differs from generic Powered by Zapier docs mainly in authentication: your backend uses token exchange and Connect for user connections. The Workflow API endpoints and payload shapes are the same as in the Zap creation guides.

​
When to use this vs other White Label patterns

  • Embedded triggers/actions — run individual actions on demand with Action Runs when you orchestrate execution.
  • Embedded workflows (this page) — users get Zaps: persistent workflows that run on Zapier (triggers, multi-step logic, filters, mapping).
  • AI agent connections & automations — MCP (listTools / callTool, Streamable HTTP) for agentic products.

​
Prerequisites

  • White Label onboarding complete — JWKS, callback URLs, JWT expectations, client credentials (Partner onboarding).
  • Server-side token exchange — partner-signed JWT to user access token with the scopes your flows need (Token exchange).
  • OAuth client configured for Workflow API — same scopes model as the broader Partner / Workflow API (Authentication); request only the scopes each endpoint requires (for example zap:write to create Zaps).
You do not need a public Zapier integration in the App Directory to use this White Label embedded workflows path.

​
What you need

  • A user access token (from token exchange), used as Authorization: Bearer on Workflow API requests.
  • A strategy to create or reuse connections (authentications) via Connect when a step requires a linked account (Connection flow, Selecting an authentication).
  • Your UI or server flow to walk apps → actions → inputs → outputs/mapping → create Zap, using the guides below.

​
High-level flow

  1. Token exchange — exchange the partner JWT for a user access token (Token exchange).
  2. Discover apps — GET /v2/apps for pickers and search (Retrieving apps).
  3. Select actions — GET /v2/actions per app (READ triggers, WRITE actions, etc.) (Selecting an action).
  4. Connections — GET /v2/authentications; route users through Connect when adding or reconnecting accounts (Connection flow).
  5. Configure inputs — POST /v2/actions/{action_id}/inputs; use .../inputs/{input_id}/choices for SELECT fields; refetch when fields invalidate or depend on other fields (Fields and fieldsets).
  6. Map between steps — POST /v2/actions/{action_id}/outputs; use {{field_id}} for two-step Zaps or {{alias.field_id}} with explicit step aliases when you have more than two steps (How to build a workflow).
  7. Optional filters — add Filter by Zapier steps (action_type=FILTER) per Filter actions.
  8. Create the Zap — POST /v2/zaps with scope zap:write (Create a Zap, How to build a workflow).
  9. Test steps (recommended) — POST /v2/actions/{action_id}/test (Testing a workflow).
  10. Operate — GET /v2/zaps with filters/expand as needed; use links.html_editor when you want a handoff to the Zapier editor (Retrieving a list of Zaps).

​
Create and manage Zaps

End-to-end construction (actions, authentications, inputs, output mapping, aliases, multi-step examples) is documented in How to build a workflow. Use that guide as the canonical walkthrough; this page wires it to White Label auth and sibling use cases. Create example shape (see API reference for full schema and expand): 
POST https://api.zapier.com/v2/zaps
Authorization: Bearer YOUR_ACCESS_TOKEN
Content-Type: application/json

{
  "data": {
    "enabled": true,
    "title": "My embedded workflow",
    "steps": [
      {
        "action": "core:TRIGGER_ACTION_ID",
        "authentication": "AUTH_ID",
        "inputs": { }
      },
      {
        "action": "core:ACTION_ACTION_ID",
        "authentication": "AUTH_ID",
        "inputs": { "field": "{{previous_step_output_id}}" }
      }
    ]
  }
}
After creation, the response may omit per-step inputs even when you sent them; that is expected (How to build a workflow).

​
What Zapier runs vs what you own

AreaZapierYour product
ExecutionSchedules/runs triggers, actions, filters, searchesDrives configuration via API; no per-step runtime polling required
Third-party credentialsStores and refreshes connectionsSurfaces Connect; refreshes authentication lists after connect
Workflow recordPersists the Zap (steps, mapping, enabled state)Your setup UX, templates, and lifecycle (draft/publish)

​
Limits and best practices

  • Steps — maximum 25 per Zap; use snake_case alias on steps when referencing outputs across more than two steps (How to build a workflow).
  • Action identity — prefer stable key for product logic; id is what the API accepts on steps and may change when app implementations change—refresh cached metadata when building UIs.
  • Zap listing scopes — which Zaps appear in GET /v2/zaps depends on granted scopes (for example zap:all vs default); see Retrieving a list of Zaps.
  • Rate limits — Workflow API requests are rate limited (Rate limiting).

​
Security notes

  • Keep client_secret, user access tokens, and connect tokens on the server.
  • Validate state on OAuth callbacks where used.
  • Prefer short-lived partner JWTs and rotate signing keys with JWKS.