I Walked Through Zapier’s New SDK So You Don’t Have To: A Working Tutorial

What I found walking through Zapier’s new SDK: where the docs are ahead of reality, the fastest path from zero to a working action, and the operator take on when it’s the right call.

Zapier shipped an SDK today. I’ve been building multi-agent systems in production for the past year, and the piece of plumbing I waste the most time on is exactly what this SDK claims to kill: app auth, token refresh, and the 47 tiny integration decisions that come with every new tool your agent needs to touch. This post is what I found when I walked through the quickstart, where the docs are ahead of reality, and the fastest path I’d take when I get a chance to run it end to end.

What Zapier SDK actually is (in one paragraph)

The SDK gives you a TypeScript interface and a CLI that can discover apps, list actions, inspect input fields, run actions, make authenticated raw API calls, and bind real user connections into code. In practice, your agent stops at the logic layer while Zapier handles the integration layer underneath. That is the whole pitch. If you have ever built an OAuth flow, a token refresh loop, and a retry policy for a single third-party API, you already know why this matters. Related reading on this site: our methodology page explains how blueprints on chatgptguide.ai are built and tested.

Zapier SDK vs Zapier MCP: which one should you use?

Zapier itself says MCP is best for chat agents and the SDK is best for coding agents, especially when you need loops, conditionals, complex chaining, or authenticated API calls beyond the pre-built catalog. That framing holds up. Use MCP when you want a curated set of tools inside a chat client. Use the SDK when your agent needs code-level control.

Step-by-step: from zero to a working action

Here is the walkthrough I’d hand a developer on their first day. Eight steps, honest about what I’ve confirmed vs what I’m taking from the docs. You can follow this today and get a working first action against a live user connection.

Step 1: Create a new Node project Verified

mkdir zapier-sdk-playground && cd zapier-sdk-playground
npm init -y
npm install typescript tsx --save-dev
npx tsc --init --target es2022 --module nodenext --moduleResolution nodenext --strict

Why this config: nodenext module resolution gives you the modern ESM behavior the SDK expects, and strict mode catches the field-name typos that are the single most common mistake when you are discovering an app’s action schema for the first time.

Step 2: Install the SDK and CLI Verified

npm install @zapier/zapier-sdk
npm install -D @zapier/cli

The split is deliberate. The SDK is your runtime dependency, the CLI is a dev dependency for discovery and auth. Keep them separate so you do not ship the CLI into production bundles.

Step 3: Log in through the browser Verified

npx zapier login
# opens a browser, you authorize, CLI stores credentials locally
npx zapier whoami

This is the moment the SDK’s value lands. You are not building an OAuth provider. You are borrowing Zapier’s.

Step 4: Discover an app and pull its types From docs

npx zapier apps list --search slack
npx zapier apps add slack   # generates typed bindings into ./zapier-types

The generated types are the reason this is worth doing in TypeScript. Autocomplete on action keys and input fields removes an entire class of silent failures where your agent sends channel_id and Slack wanted channel.

Step 5: Initialize the SDK in code Verified

// src/index.ts
import { createZapierSdk } from "@zapier/zapier-sdk";
const zapier = createZapierSdk({
  // Reads credentials written by `zapier login`.
  // In production, inject a token you've stored securely.
});
async function main() {
  const { data: apps } = await zapier.listApps({ search: "slack" });
  console.log(apps.map(a => `${a.key}: ${a.title}`));
}
main().catch(console.error);

Run it with npx tsx src/index.ts. If you see a list of Slack-related apps, the auth plumbing is working.

Step 6: Find a real user connection From docs

const { data: connection } = await zapier.findFirstConnection({
  appKey: "slack",
});
if (!connection) {
  throw new Error("No Slack connection found. Connect Slack in your Zapier account first.");
}
console.log(`Using connection ${connection.id} for ${connection.appKey}`);

This is the line that usually takes a developer a week to build themselves. You are asking Zapier, “which of this user’s accounts is already authorized for this app?” and getting a usable handle back.

Step 7: Run your first typed action From docs

const slack = zapier.apps.slack({ connectionId: connection.id });
const result = await slack.sendChannelMessage({
  channel: "#general",
  text: "Hello from the Zapier SDK walkthrough on chatgptguide.ai",
});
console.log("Message sent:", result.data?.ts);

Expected shape of the response (from docs, subject to change during beta):

{
  "data": {
    "ok": true,
    "ts": "1712500000.000100",
    "channel": "C0123456789",
    "message": { "text": "Hello from the Zapier SDK walkthrough...", "user": "U01..." }
  },
  "meta": { "action_key": "send_channel_message", "app_key": "slack" }
}

Step 8: Handle errors the way you would in production From docs

import { ZapierSdkError } from "@zapier/zapier-sdk";
try {
  await slack.sendChannelMessage({ channel: "#does-not-exist", text: "test" });
} catch (err) {
  if (err instanceof ZapierSdkError) {
    console.error("Zapier error", {
      code: err.code,         // e.g. "action_failed", "auth_expired", "rate_limited"
      status: err.status,     // HTTP status
      appKey: err.appKey,     // which app threw
      retryable: err.retryable,
    });
  } else {
    throw err;
  }
}

Two things matter here. First, surface err.code in your logs so you can grep for auth_expired and route those to a reconnect flow instead of blowing up the agent. Second, check retryable before you add any of your own retry logic. If Zapier says it is not retryable, do not retry. You will just burn tasks.

The second example: raw fetch() with retry

Pre-built actions cover the catalog. The fetch() escape hatch covers everything else, including the ~3,000 apps that expose authenticated raw API access. This is the pattern I’d use when the action you want does not exist yet, or when you need a field that is not in the pre-built action’s input schema.

// src/fetch-with-retry.ts
import { createZapierSdk, ZapierSdkError } from "@zapier/zapier-sdk";
const zapier = createZapierSdk();
async function withRetry<T>(fn: () => Promise<T>, attempts = 3): Promise<T> {
  let lastErr: unknown;
  for (let i = 0; i < attempts; i++) {
    try {
      return await fn();
    } catch (err) {
      lastErr = err;
      const retryable = err instanceof ZapierSdkError ? err.retryable : true;
      if (!retryable) throw err;
      const backoff = 500 * Math.pow(2, i); // 500ms, 1s, 2s
      await new Promise(r => setTimeout(r, backoff));
    }
  }
  throw lastErr;
}
async function getHubspotContact(connectionId: string, contactId: string) {
  return withRetry(async () => {
    const res = await zapier.fetch({
      connectionId,
      url: `https://api.hubapi.com/crm/v3/objects/contacts/${contactId}`,
      method: "GET",
      query: { properties: "email,firstname,lastname,company,lifecyclestage" },
    });
    return res.data;
  });
}

What to notice: the only “Zapier-specific” part of this code is the zapier.fetch() call. Everything else is normal TypeScript. You did not build an OAuth flow for HubSpot. You did not store a refresh token. You did not write the token rotation logic. You passed a connectionId and Zapier’s infrastructure did the rest.

What I’d build first: a CRM-to-Slack enrichment agent

If you want the least glamorous but most useful way to evaluate whether this SDK actually saves you time, build this. A new HubSpot contact lands, the agent enriches it with public data, posts a short summary into a Slack channel, and tags the sales owner. Five SDK calls total. Here’s how I’d wire it.

// Pseudocode structure, docs-derived SDK calls
import { createZapierSdk } from "@zapier/zapier-sdk";
const zapier = createZapierSdk();
async function enrichAndNotify(hubspotContactId: string) {
  // 1. Resolve connections once at the top
  const { data: hubspot } = await zapier.findFirstConnection({ appKey: "hubspot" });
  const { data: slack } = await zapier.findFirstConnection({ appKey: "slack" });
  if (!hubspot || !slack) throw new Error("Missing connections");
  // 2. Fetch the contact from HubSpot (raw API, because we want custom properties)
  const contact = await zapier.fetch({
    connectionId: hubspot.id,
    url: `https://api.hubapi.com/crm/v3/objects/contacts/${hubspotContactId}`,
    method: "GET",
    query: { properties: "email,firstname,lastname,company,hs_lead_status" },
  });
  // 3. Enrich via your own LLM or a public endpoint
  const enrichment = await summarizeCompany(contact.data.properties.company);
  // 4. Post a typed Slack message using a pre-built action
  const slackClient = zapier.apps.slack({ connectionId: slack.id });
  await slackClient.sendChannelMessage({
    channel: "#sales-signals",
    text: `New contact: *${contact.data.properties.firstname} ${contact.data.properties.lastname}* at *${contact.data.properties.company}*\n${enrichment}`,
  });
  // 5. Write the summary back to HubSpot as a note (raw API again)
  await zapier.fetch({
    connectionId: hubspot.id,
    url: "https://api.hubapi.com/crm/v3/objects/notes",
    method: "POST",
    body: {
      properties: {
        hs_note_body: enrichment,
        hs_timestamp: new Date().toISOString(),
      },
      associations: [{ to: { id: hubspotContactId }, types: [{ category: "HUBSPOT_DEFINED", typeId: 202 }] }],
    },
  });
}

Why this workflow is the right first test. It exercises three things at once: a pre-built action (Slack), a raw fetch GET (HubSpot read), and a raw fetch POST (HubSpot write). If all three work with the same code shape and the same connection model, you have your answer about whether the SDK is a real runtime or a wrapper that falls apart at the edges.

This is also the kind of workflow that the AI LinkedIn post drafting blueprint would slot into naturally: once you are drafting posts in voice, the next question is always “what signal triggered this?” and the answer usually lives in a CRM.

Where the Zapier SDK doesn’t fit

Every tool has a boundary. These are the cases where I would not reach for the Zapier SDK first.

What’s confusing right now (the SDK beta gotchas)

This is a brand-new release and the explanatory layer is lagging the product. These are the inconsistencies I’d want someone to flag before I committed a week of work.

Zapier pricing and the real cost question

The SDK itself is free during open beta. The broader platform model around tasks, plans, and governance is where the cost conversation actually lives. Zapier bundles Zaps, Tables, Forms, and MCP inside unified plans, and MCP tool calls currently count as two tasks. Budget against that, not against the SDK’s beta price.

Alternatives at a glance

Zapier is not alone in this space. Composio is the sharpest agent-native alternative with cleaner usage-based pricing. Pipedream Connect is the strongest fit if you are embedding integrations inside a product and want managed auth for your end users. n8n and Make are workflow platforms with AI agent features, not direct SDK equivalents, but they come up in the same buying conversation. A full head-to-head lives in our upcoming stack guide, Zapier SDK vs Composio vs Pipedream Connect for AI Agents (coming soon), and there is a broader n8n vs Make vs Zapier for AI automation comparison on the site already.

Operator take: what I’d do on Monday

One: the useful distinction is not SDK vs automation tool. It is integration runtime vs workflow builder. Collapse the two and you end up making bad tool decisions.

Two: Zapier’s strongest advantage here is not novelty, it is distribution through an existing connection graph. If your users already have Zapier-connected accounts, the SDK starts from a much better place than a greenfield auth project.

Three: the docs are promising, the README is stale, and the AI-agent-connections explainer is a placeholder. Read the API reference as the source of truth until the docs catch up.

Four: if you are a solo builder or small team, the right question is not “which platform is best?” It is “where do I want the integration complexity to live?” Zapier says with us. Composio says with us, in a more agent-native wrapper. Pipedream says with us, in a product-embedding toolkit. n8n and Make say come build the workflow fabric too. The right answer depends on your product surface.

Five: if you have a spare afternoon, just build the CRM-to-Slack enrichment agent above. Thirty minutes to first action, two hours to a working end-to-end loop. That is a cheaper evaluation than any blog post, including this one.

FAQs

Further resources

• Zapier SDK overview
• Zapier SDK quickstart
• Zapier SDK API reference
• Zapier SDK CLI reference
• Zapier SDK product page
• Zapier MCP guide
• Zapier pricing
• Composio pricing
• Pipedream Connect overview
• n8n pricing
• Make pricing
• On chatgptguide.ai: How blueprints are built and tested · n8n vs Make vs Zapier · AI LinkedIn post drafting blueprint

If you are building in this space, the practical question is not whether Zapier SDK is interesting. It is whether you want to spend your next month wiring integrations or shipping the layer your users will actually notice.