Struggling to chain Apify Actors in Zapier? Discover why simply passing a run ID fails and learn three distinct solutions, from a quick fix to a robust architectural pattern, to get your data flowing correctly.

I See You’re Stuck Chaining Apify Actors in Zapier. Let’s Talk.

I remember this one time, about 3 AM, staring at a failing deployment pipeline. We had a simple job: a microservice that processed images (let’s call it `image-proc-svc`) was supposed to hand off a JSON payload with image URLs to another service (`metadata-enrich-svc`). It worked perfectly in staging. In production? Silence. The logs for `metadata-enrich-svc` were bone dry. After two hours of tearing my hair out, I found it. The `image-proc-svc` was sending a JSON object containing a `jobId`, but the enrichment service was expecting an array of `urls`. It was a classic “you sent me the box, not the stuff inside the box” problem. The system wasn’t broken; my assumptions were.

That’s the exact same feeling I get when I see folks struggling to connect two Apify Actors in Zapier. It feels like it should “just work,” but it fails silently, leaving you wondering what you did wrong. You didn’t do anything wrong. You just misunderstood what kind of box Apify is handing to Zapier.

The “Why”: You’re Passing the Receipt, Not the Groceries

Here’s the fundamental issue. When you use the “Run Actor” action in Zapier for your first Apify Actor (let’s call it Actor A), the immediate output from that step is not the data it scraped. It’s a summary of the run itself. Think of it as a receipt. It has details like the `runId`, `status`, `startTime`, and, crucially, the `defaultDatasetId`.

Your second Apify Actor (Actor B) doesn’t know what to do with a `runId`. It’s expecting data to work on—a list of URLs, some text, a JSON object. When you map the `runId` from Actor A into the input of Actor B, you’re handing it the receipt and asking it to cook dinner. It’s not going to work.

Here’s a simplified look at the JSON output from a “Run Actor” step:

{
  "id": "abCDeF12345",         // This is the Run ID (the "receipt")
  "actId": "my-cool-scraper",
  "status": "SUCCEEDED",
  "defaultDatasetId": "zyXWvU98765", // This is the ID for the data (the "groceries")
  "containerUrl": "https://console.apify.com/..."
  // ...and other metadata
}

The goal is to get the data from the `defaultDatasetId` and pass that to your second actor. So, how do we do it? We have a few options, ranging from “quick and dirty” to “architecturally sound.”

Solution 1: The Quick Fix (The “Duct Tape” Method)

This is the fastest way to get things working, but it can be a bit brittle. Some Apify Actors are smart enough to accept a Dataset ID as their input. Instead of giving it the raw data, you just tell it where to find the data on the Apify platform.

Steps:

1. In your Zap, after your first “Run Actor” step (Actor A), set up your second “Run Actor” step (Actor B).
2. In the “Action” setup for Actor B, look for its input configuration field. This might be “Start URLs”, “Input JSON”, or a custom field.
3. Instead of mapping any other fields, find the “Default Dataset ID” from the output of Actor A. Map this directly into the input field of Actor B.

For an actor that accepts a dataset ID in its JSON input, you would map it like this:

{
  "sourceDatasetId": "zyXWvU98765" // Mapped from Actor A's output
}

Darian’s Take: I call this the duct tape method because it relies on Actor B being specifically designed to accept a `datasetId`. If it’s not, this will fail. It’s a handy shortcut for actors designed to work in a chain, but it’s not a universal solution. Use it when you need a result now.

Solution 2: The Permanent Fix (The “Right Way” in Zapier)

This is the most reliable and explicit method within the standard Zapier workflow. It involves adding an extra step to explicitly fetch the results from the first run before passing them to the second.

Steps:

1. Step 1: Apify – “Run Actor” (Your Actor A). Nothing changes here.
2. Step 2 (The New Step): Add a new action. Search for Apify and choose the “Get Dataset Items” action.
3. In the “Get Dataset Items” setup, it will ask for a “Dataset ID”. Map the “Default Dataset ID” from the output of Step 1 into this field.
4. Step 3: Apify – “Run Actor” (Your Actor B). In this step’s input configuration, you will now see the data from Step 2. You can map the actual fields (like `url`, `title`, etc.) from the dataset into Actor B’s input.

This flow is unambiguous: Run Job -> Get Job’s Data -> Use Data in Next Job.

Heads Up: This method uses one extra Zapier task per run, which can affect your monthly bill. For low-volume workflows, it’s a non-issue. For high-volume, see the next solution. But for clarity and maintainability, this is my default recommendation.

Solution 3: The ‘Nuclear’ Option (The Event-Driven Architect’s Way)

Sometimes, you don’t want Zapier polling and waiting for an Apify run to finish. This is slow and inefficient. The professional-grade solution is to reverse the logic: have Apify tell Zapier when the first job is done.

This uses Apify Webhooks and Zapier’s “Catch Hook” trigger.

High-Level Steps:

1. In Zapier: Create a new Zap. For the trigger, choose “Webhooks by Zapier” and the event “Catch Hook”. Zapier will give you a unique URL. Copy it.
2. In Apify: Go to your Actor A’s settings, find the “Webhooks” section, and create a new webhook. Paste the Zapier URL there. Set the event to trigger on “Run succeeded”. The payload will automatically contain the run details, including the `resource.defaultDatasetId`.
3. Back in Zapier: Run a test of Actor A in Apify to send data to the webhook so Zapier can “learn” the structure.
4. Add your Apify “Get Dataset Items” and “Run Actor” (Actor B) steps to the Zap, using the data from the webhook trigger.

This turns your workflow from a “pull” model (Zapier checking on Apify) to a “push” model (Apify telling Zapier). It’s how we build our internal event-driven systems at TechResolve, and it’s the most scalable solution by far.

So, next time you’re stuck, remember my 3 AM debugging session. Are you handing over the box, or the stuff inside? Making that distinction is the key to unlocking these powerful automation workflows.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions