🚀 Executive Summary

TL;DR: Connecting two Apify Actors in Zapier often fails because the initial ‘Run Actor’ step provides a run ID and dataset ID (metadata) instead of the actual scraped data. To resolve this, users must explicitly fetch the dataset items using the ‘defaultDatasetId’ before passing them to the subsequent actor, ensuring the correct data payload is received.

🎯 Key Takeaways

• The ‘Run Actor’ action in Zapier for an Apify Actor outputs run metadata (e.g., ‘runId’, ‘defaultDatasetId’), not the actual scraped data.
• To correctly chain Apify Actors in Zapier, you must use the ‘defaultDatasetId’ from the first actor’s run output to explicitly retrieve the dataset items via a ‘Get Dataset Items’ step.
• For event-driven and scalable workflows, Apify Webhooks can be configured to trigger a Zapier ‘Catch Hook’ upon successful actor completion, pushing the ‘defaultDatasetId’ for subsequent processing.

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.

👉 Read the original article on TechResolve.blog

☕ Support my work

If this article helped you, you can buy me a coffee:

👉 https://buymeacoffee.com/darianvance