Fix n8n Mailchimp Batch Operations Failing "Resource Not Found" While Single Calls Work

Why batch and single-call behavior can genuinely diverge

Mailchimp's batch operations endpoint accepts an array of individual API operations (each with its own method and path) and executes them asynchronously, returning a batch ID you poll for results. A documented issue on Mailchimp's own API examples repository describes every operation inside a batch erroring as resource-not-found even though the same list clearly exists and the same operation works fine when sent individually outside the batch context — which points at how the batch endpoint resolves each embedded operation's path, not at the underlying data.

This is a genuinely confusing failure because the natural response — double-checking that the list ID is correct — will not find anything wrong, since the ID is correct; the problem is specific to the batch execution path.

How a Mailchimp batch request is actually structured

Each embedded operation in the batch array needs its own relative `path` (not a full URL), a `method`, and, for writes, a `body` as a JSON string. A malformed embedded path — for example, accidentally including the full https://... domain instead of a path starting with /lists/... — is a separate, more mundane cause of the identical resource-not-found symptom, so ruling out the request shape itself is worth doing before assuming the platform-level quirk is the cause.

POST https://<dc>.api.mailchimp.com/3.0/batches
{
  "operations": [
    {
      "method": "PATCH",
      "path": "/lists/<list_id>/members/<subscriber_hash>",
      "body": "{\"merge_fields\":{\"FNAME\":\"Test\"}}"
    }
  ]
}

// Response returns a batch "id" — poll GET /batches/<id> until status is "finished"
// then inspect the response_body_url for per-operation results.

Confirm this is the batch-specific issue, not a real ID or path problem

• Run one of the failing operations individually (outside the batch) using the exact same list/member ID — if it succeeds standalone, the ID is correct and the batch mechanism itself is the variable.
• Check that the operation paths inside the batch array are correctly formed as relative paths (not full URLs), since a malformed embedded path is a separate, more mundane cause of the same symptom that is worth ruling out first.
• Confirm you are polling the batch status endpoint correctly and reading the per-operation response from the response_body_url once status is "finished", since a batch can partially succeed and partially fail — treat each operation's individual status, not just the overall batch status, as the source of truth.

Workaround: chunk into individual calls when batch results are unreliable

If individual operations succeed but the same operations consistently fail inside a batch, the practical fix in an n8n workflow is to avoid the batch endpoint for the affected operation type and instead use Loop Over Items with individual Mailchimp API calls, accepting the tradeoff of more requests (and being mindful of Mailchimp's own rate limits on individual calls) in exchange for reliable per-record results.

For larger volumes where individual calls would be too slow, batch by a smaller, controlled chunk size and validate a sample of operations from the batch result before trusting the full run, rather than assuming an all-or-nothing outcome.

Sources checked for this guide

This is a documented issue against Mailchimp's own official API examples repository, confirming it as a platform-level batch behavior rather than an n8n-specific bug.