OpenAI and Anthropic Batch APIs in n8n: cut your AI call costs in half

An n8n workflow that calls an LLM in real time pays full price, line by line, second by second. That's justified for a chatbot or an urgent alert — much less so for an email digest sent once a day, an overnight document ingestion, or a monthly compliance report. For processing that can tolerate a few hours of delay, both OpenAI and Anthropic offer a Batch API: the same models, at half price, in exchange for asynchronous processing. n8n has no dedicated node for it, but a plain HTTP Request node is enough to orchestrate the whole cycle — submission, waiting, retrieving results.

The principle: submit a batch, get results later

Both providers follow the same logic, with different implementation details.

OpenAI: you upload a .jsonl file (one request per line, each with a custom_id, a method, a target endpoint url, and a body) via POST /v1/files with purpose=batch, then create the batch with POST /v1/batches, pointing to that file and picking a target endpoint (/v1/chat/completions, /v1/embeddings, /v1/responses…) and a 24-hour completion window. Once the status moves to completed, an output_file_id becomes available and is fetched via GET /v1/files/{id}/content.

Anthropic: more direct, no separate file step. POST /v1/messages/batches takes a requests array straight in the body, each entry carrying a custom_id and params identical to a regular /v1/messages call (tool use included) — up to 100,000 requests per batch. Status is checked via GET /v1/messages/batches/{id}; once it flips to ended, the results_url field points to a .jsonl file of results.

In both cases, the discount is 50% off input and output tokens, with an advertised SLA of 24 hours — in practice, most small batches come back within one to four hours.

Why it's cheaper: not an arbitrary discount

This price cut reflects a real server-side efficiency gain, not a marketing gesture. Serving requests one at a time under-uses the GPU; batching them together lets a lot more tokens get processed per compute cycle. That's exactly the mechanism documented by Woosuk Kwon and coauthors in «Efficient Memory Management for Large Language Model Serving with PagedAttention» (SOSP 2023, the founding paper behind the vLLM inference engine): by managing the memory of in-flight requests in pages instead of contiguous blocks, the system can run far more requests in parallel on the same hardware, multiplying throughput several times over compared to naive sequential serving. A provider that can defer your requests by a few hours can batch them with other customers' requests during off-peak windows — hence the discount, which is economically grounded rather than arbitrary.

Which n8n workflows fit (and which don't)

The test is simple: can the processing wait without anyone noticing?

Good candidates:

• The daily digest of the Inbox AI Pack: if the overnight email triage only lands in Slack at 8am, classifying 200 emails at 2am through a batch instead of one synchronous call per email doesn't change anything for the user — and cuts the classification bill in half.
• The document ingestion of the RAG Assistant Pack: generating embeddings for a batch of PDFs or an overnight Notion sync (see our RAG guide with Supabase pgvector and our comparison on choosing an embeddings model) has zero latency constraint — OpenAI's Batch Embeddings accepts up to 50,000 inputs per batch.
• The periodic reports of the Compliance & Audit Pack: a weekly or monthly AI-generated summary, where a few hours of delay carry no consequence.

Bad candidates: anything answering a human who's waiting — a chatbot, an on-site chat widget, a reply to an incoming Slack or WhatsApp message. For those, stick with the classic synchronous call and work instead on the pacing described in our article on rate limits and Loop Over Items, or the load distribution of queue mode with Redis.

Implementation in n8n: two separate workflows

The simplest approach splits the orchestration into two independent n8n workflows rather than keeping a single execution waiting for hours.

1. Submitting the batch

A Schedule Trigger (say, 2am) kicks off collecting the items to process — the day's emails from a Supabase table, the documents added since the last sync. A Code node then builds the array of requests, assigning each item a custom_id that will let you match it back on the way out (the email or document's database ID, for instance). For Anthropic, that array goes straight into the body of the POST /v1/messages/batches call via an HTTP Request node; for OpenAI, it needs to be written as .jsonl first and uploaded via POST /v1/files (purpose=batch), before creating the batch with POST /v1/batches. In both cases, the HTTP Request node's "Predefined Credential Type" authentication option recognizes the OpenAI or Anthropic credentials you've already configured for your Chat Model nodes — no need to recreate a dedicated key. The batch_id (or id on OpenAI's side) returned by the call gets logged into a Supabase table with a status of in_progress.

2. Checking status and retrieving results

A second Schedule Trigger, running every 30 minutes say, checks GET /v1/messages/batches/{id} (Anthropic) or GET /v1/batches/{id} (OpenAI) for each batch logged as in_progress. An IF node tests the status: ended on Anthropic's side, completed on OpenAI's. As long as it isn't there yet, the workflow simply stops — it will run again on the next schedule, with no execution left hanging for hours (the same instinct as webhook idempotency: every run is independent and replayable). Once the status is favorable, an HTTP Request node fetches the results — via results_url (Anthropic) or GET /v1/files/{output_file_id}/content (OpenAI) — and a Code node (possibly preceded by a Split Out) walks the .jsonl, matches each result back to its original custom_id, and writes the model's response into the corresponding Supabase row, exactly as a synchronous call would have.

Pitfalls and limits

• No multi-turn function calling: a batch processes each request independently, without the tool-calling back-and-forth the AI Agent node relies on. For workflows that depend on it (see our article on custom AI Agent tools), the synchronous call remains necessary.
• A partially failed batch is still usable: every result line carries its own status, tied to its custom_id. One failing request (content too long, formatting error) doesn't block the rest of the batch's results — just plan a branch to retry or log individual errors.
• Pair it with a fallback if the delay isn't guaranteed: for time-sensitive processing (a report due before a legal deadline), keep a fallback to the synchronous call in case the batch doesn't come back within the expected window — the same principle covered in our article on multi-provider AI fallback.

Key takeaways

OpenAI's and Anthropic's Batch APIs need no special node in n8n: an HTTP Request to submit, a Schedule Trigger to check status periodically, another HTTP Request to retrieve results via their custom_id. In exchange for a few hours of delay instead of an instant reply, the input and output token bill is cut in half — a direct win on anything that never needed to be real-time: a daily digest, overnight document ingestion, a periodic report. The workflows in the Inbox AI Pack (€79), RAG Assistant Pack (€119) and Compliance & Audit Pack (€149) — bundled together in the Complete FlowKit Bundle (€269 instead of €347) — are built to run as synchronous calls straight out of the box; wiring a Batch job ahead of the non-urgent steps is an optimization to add once real volume shows up, not a prerequisite.