API chaining is using the output of one API call as the input to the next. Convert a file, then read the text out of it, then summarise the text. Three calls where each one depends on the result of the one before.
It sounds trivial and it is, right up until any of the three fails, or one gets slow, or they belong to three different vendors with three different rate limits.
Two things changed in 2026. The first is that AI agents now build chains at runtime rather than executing ones you wrote in advance, which makes the sequence non-deterministic and the cost unpredictable. The second is that the chains themselves got longer, because assembling five capabilities is now cheaper than building one.
This covers the patterns, the failure modes, four worked examples, and the part most guides skip: chaining calls across services you do not control is a substantially different problem from chaining calls within one.
01Chaining, Aggregation, and Orchestration
Three terms that get used interchangeably and mean different things.
| Term | What it is | Example |
|---|---|---|
| Chaining | Output of one call becomes input to the next. Sequential and dependent. | Convert a PDF, then OCR the result, then extract entities |
| Aggregation | Several independent calls combined into one response. Parallel. | Fetch a product's price, stock, and reviews at once |
| Orchestration | A coordination layer managing sequence, state, retries, and branching across many calls | A workflow engine running the whole thing with error paths |
Chaining is the building block. Aggregation is chaining's parallel sibling. Orchestration is what you end up building once you have enough of both.
Most people asking about API chaining need the first one and are being sold the third.
02Four API Chaining Examples You Can Actually Build
Abstract chaining advice is easy to write and hard to use. Here are four real chains, each built from endpoints in the ApyHub API catalog, with the failure point in each one named.
1. Invoice processing: from a scanned PDF to validated structured data
The most common document chain there is, and the one that shows every chaining problem at once.
| Step | Endpoint | What it does |
|---|---|---|
| 1 | OCR Document Data Extraction | Reads text out of the scanned PDF |
| 2 | AI Document Invoice Data Extraction | Returns merchant, date, totals, line items as fields |
| 3 | Validate EU VAT | Confirms the supplier's VAT number is real |
| 4 | Validate IBAN | Confirms the payment details are well-formed |
| 5 | AI Summarize Documents | One-line description for the finance ledger |
Where it breaks: steps 3 and 4 have no dependency on each other and should run in parallel. Most implementations run them sequentially because that is the order they appear in the spec.
The chaining lesson: OCR output for a given file never changes, so cache step 1. If step 5 fails, re-running the whole chain re-pays for the most expensive call in it.
2. Merchant onboarding: is this business real
A verification chain, and a good example of conditional chaining, since most applications should exit early.
| Step | Endpoint | What it does |
|---|---|---|
| 1 | Calculate Domain Age | How long has this domain existed |
| 2 | Domain WHOIS Lookup | Registrar, expiry, name servers |
| 3 | Validate EU VAT | Is the company registration real |
| 4 | Validate Email DNS | Does the contact address accept mail |
| 5 | Generate Webpage Screenshot | Evidence for the human reviewer |
Where it breaks: running all five on every applicant wastes calls. Step 1 costs almost nothing and rejects a meaningful share on its own, so it should gate the rest. That is conditional chaining rather than a fixed sequence.
The chaining lesson: order your chain by cost ascending and rejection rate descending. Cheap decisive checks first.
3. Content pipeline: from a URL to a summary in another language
A content chain, and the one where latency stacking is most visible to a user waiting on it.
| Step | Endpoint | What it does |
|---|---|---|
| 1 | Extract Text from Webpage | Readable content, no navigation or markup |
| 2 | AI Summarize | Condenses it |
| 3 | Extract Named Entities from Text | People, companies, places mentioned |
| 4 | Text Sentiment Analyzer | Tone of the piece |
| 5 | Translate Documents | Into the reader's language |
Where it breaks: steps 2, 3, and 4 all take the same input from step 1 and none of them need each other. Run in parallel this chain is two round trips deep instead of five.
The chaining lesson: draw the dependency graph before writing the code. Most chains are shallower than the order they were described in.
4. Report generation: from data to a delivered file
An output chain, and the one most likely to need a background job.
| Step | Endpoint | What it does |
|---|---|---|
| 1 | Convert Markdown to PDF | Renders the report |
| 2 | Compress Images | Reduces attachment size |
| 3 | Generate Secure Archives | Password-protected bundle |
Where it breaks: file steps are frequently asynchronous. Mixing a synchronous call with a job that returns an ID to poll means two different code paths in one chain, and it is the single most common source of chaining bugs.
The chaining lesson: check whether each endpoint is sync or job before you design the chain, not while debugging it. ApyHub labels this on every service listing.
What the four have in common
Every one of them crosses what would normally be a vendor boundary. Invoice processing touches OCR, extraction, financial validation, and summarisation. In most stacks that is four suppliers, four keys, four error formats, and four quotas.
Here they are one key, one error convention, and one pool of atoms spendable across every step. That is the difference between a chain being an afternoon and a chain being a project.
03The Patterns
Sequential. Each call waits for the one before. Simplest, slowest, and the only option when there is a real dependency.
Parallel. Independent calls fired at once, results combined. Use this whenever steps do not depend on each other. Validating an email address and validating a phone number have nothing to do with each other and should not queue.
Conditional. The result of one call decides which call comes next. If the document is a receipt, use receipt extraction. If it is an invoice, use invoice extraction. This is where chains stop being scripts and start being logic.
Fan-out and fan-in. One result produces many calls, whose results are collected back. Extract fifty URLs from a sitemap, check each one, aggregate the failures.
Most real workflows use all four. The mistake is running everything sequentially because it was easier to write.
A fifth pattern arrived properly in 2026: agent-determined. Nobody writes the sequence. The agent picks the first call, reads the result, and chooses the second based on what came back. More on that below, because it changes the failure modes rather than just the authoring.
04What Actually Breaks
Latency stacks
Five sequential calls at 300ms each is a second and a half before your user sees anything. Nobody plans for this, everybody hits it.
The fix is usually structural rather than clever: identify which steps genuinely depend on each other and parallelise the rest. In the invoice chain above, VAT validation and IBAN validation can happen at the same time. They are separate steps for narrative convenience, not because one needs the other.
Partial failure is the normal case
In a five-step chain, the interesting question is not what happens when it works. It is what happens when step four fails after steps one through three succeeded and cost money.
Three approaches:
Retry the failed step. Works if the step is idempotent, meaning running it twice produces the same result as running it once. Most read operations are. Many write operations are not.
Fail the whole chain and start over. Simple, wasteful, and fine for cheap chains.
Compensating actions. Undo the steps that succeeded. Correct, and considerably more work than people expect.
Pick one deliberately. The default of "retry everything and hope" produces duplicate records.
Rate limits do not compose
Each service has its own limit. A chain moves at the speed of its most restrictive step, and a burst of parallel work hits that limit faster than sequential work does.
Fan-out is where this bites hardest. Extracting a sitemap of 500 URLs and immediately firing 500 requests will exceed something. Batch, queue, and back off.
Auth and quota fragmentation
This is the one that has nothing to do with your code.
Five vendors means five API keys, five dashboards, five billing relationships, five sets of rate limits, and five separate quotas that do not pool. Run out on one and the chain stops, regardless of how much headroom you have on the other four.
A chain is only as available as its least-provisioned link.
05Chaining Across Vendors Is the Hard Part
Everything above is manageable within one service. The difficulty is that real chains rarely stay inside one.
The invoice chain above touches OCR, document extraction, financial validation, and summarisation. If those are four vendors, you are managing:
- Four authentication schemes, at least one of which uses OAuth for no good reason
- Four error formats, so your handler needs four branches to answer "did this fail"
- Four rate limits that interact unpredictably under load
- Four quotas that cannot cover for each other
- Four status pages to check when something breaks at 3am
None of that is interesting engineering. All of it is work.
This is the argument for consuming a chain through one interface. In the ApyHub API catalog, all four chains above run on one key, with one error convention, and one pool of atoms spendable across every step. If OCR turns out heavier than expected, it draws from the same balance as translation rather than exhausting a separate OCR quota while translation credit sits unused.
That pooling matters more in chains than anywhere else, because a chain fails at its weakest quota rather than its average one.
06Practical Guidance
Make every step idempotent if you can. It turns retry from a design problem into a configuration setting.
Log the whole chain, not each call. A correlation ID that follows one document through all five steps is the difference between debugging in ten minutes and debugging in two hours.
Set a total budget, not per-call timeouts. Users care about the whole operation. Five calls with generous individual timeouts can add up to a wait nobody will sit through.
Cache the stable steps. In the invoice chain, OCR output for a given file never changes. Re-running it because step five failed is pure waste.
Handle sync and async differently. Some steps answer in the request, some are jobs that return an ID to poll. Mixing both in one chain is normal and needs different code paths. ApyHub labels each service sync or job on its listing, so you can plan for it before writing anything.
Move long chains off the request path. If the whole thing takes more than a couple of seconds, return a job ID and let the client poll. Holding an HTTP connection open through five dependent calls is how request workers get exhausted.
07How AI Agents Chain API Calls
This is the part that changed most in 2026, and it is worth treating separately because agents do not chain the way application code does.
You describe the outcome rather than the sequence. The agent picks a first call, reads the result, and decides the second based on what came back. Take the invoice chain above: an agent given a scanned file and told to file the expense will run OCR, see that the result looks like an invoice rather than a receipt, choose invoice extraction over receipt extraction, notice a VAT number in the output, and validate it. Nobody wrote that order.
That only works if the agent can discover what is available. Every endpoint in the ApyHub catalog is MCP-ready, so an agent can search for a capability, read what it costs in atoms, call it, and chain to the next based on the output. Without a discovery protocol the agent can only use tools it was handed up front, which is a fixed chain wearing a costume.
Five consequences worth planning for.
Chains become non-deterministic. Run the same task twice and you may get a different sequence. Useful for exploration, a problem for anything requiring an audit trail. Log the calls, not just the outcome.
Error messages become load-bearing. An agent that receives a bare 400 has nothing to work with and gives up. One that receives a message naming the missing parameter fixes its own call and retries. In agent chains, error quality is the difference between recovery and failure, which is a stronger claim than it was when a human read the logs.
Cost becomes unpredictable. A fixed chain costs the same every run. An agent deciding its own path does not. This is an argument for pricing that scales with work performed rather than a flat per-call rate, so a heavy step is priced honestly instead of being cross-subsidised by cheap ones you did not make.
Discovery cost is separate from execution cost. Every tool definition an agent carries occupies context on every turn. A catalog handed over as hundreds of definitions is expensive before the chain starts. Search-based discovery, where the agent retrieves only what the task needs, keeps that cost proportional to the work.
Partial failure gets harder, not easier. An agent that fails at step four may retry, may try a different endpoint, or may declare success on incomplete data. Idempotent steps and clear terminal errors matter more here than in a chain you wrote yourself.
The practical upshot: the properties that make a chain agent-friendly are the same ones that make it maintainable by a human. Discoverable capabilities, honest errors, idempotent steps, and a cost model that reflects work done.
08When You Need a Workflow Engine
Chaining a handful of calls in application code is fine. You need something heavier when:
- The chain runs longer than a request and needs durable state
- Steps must survive a process restart
- You need visibility into where in-flight workflows currently sit
- Compensating actions matter, because money or records are involved
- Non-engineers need to see or change the sequence
Below that bar, a workflow engine is infrastructure you did not need. Above it, hand-rolled chaining becomes the thing you regret.
09Conclusion
API chaining is one idea: the output of one call feeds the next. Everything difficult about it comes from what happens around that.
Latency stacks, so parallelise what is genuinely independent. Partial failure is the normal case, so decide between retry, restart, and compensation before you need to. Rate limits do not compose, so batch your fan-outs.
And the part that has nothing to do with your code: a chain across five vendors is five auth schemes, five error formats, and five quotas that cannot cover for each other. Reducing that surface is usually the highest-leverage thing you can do to a chain, and it is not a code change.
That matters more in 2026 than it did, because the caller is increasingly an agent choosing its own sequence. A chain an agent can discover, call, and recover from is a chain a person can maintain.
10FAQ
What is API chaining?
API chaining is using the output of one API call as the input to the next, creating a sequence where each step depends on the result of the one before. Converting a document, then extracting its text, then summarising that text is a three-step chain.
What is the difference between API chaining and API orchestration?
Chaining is the pattern of feeding one call's output into the next. Orchestration is a coordination layer that manages sequence, state, retries, branching, and error handling across many calls. Chaining is the building block; orchestration is the system you build once you have enough of them.
What is the difference between chaining and aggregation?
Chaining is sequential and dependent: each call needs the previous result. Aggregation is parallel and independent: several calls run at once and their results are combined into a single response. Aggregation is faster because nothing waits.
How do I handle errors in an API chain?
Decide between three approaches before you need them. Retry the failed step if it is idempotent. Fail the whole chain and start over, which is simple but wasteful. Or run compensating actions to undo the steps that already succeeded, which is correct and considerably more work. Retrying blindly on non-idempotent steps produces duplicates.
What does idempotent mean in an API chain?
An idempotent operation produces the same result whether it runs once or several times. Most reads are idempotent. Many writes are not. Making chain steps idempotent turns retry from a design problem into a configuration option.
How do I make an API chain faster?
Identify which steps genuinely depend on each other and run everything else in parallel. Five sequential calls at 300ms each is 1.5 seconds; the same five in parallel is 300ms. Also cache steps whose output cannot change, so a failure late in the chain does not force re-running everything.
How do rate limits affect API chaining?
A chain moves at the speed of its most restrictive step, and each service in the chain has its own limit. Fan-out patterns hit limits hardest, since extracting fifty URLs and immediately requesting all fifty will exceed something. Batch, queue, and back off exponentially rather than retrying immediately.
Should an API chain run in a request or a background job?
If the whole chain completes in under a couple of seconds, a request is fine. Beyond that, return a job identifier and let the client poll, because holding an HTTP connection open through several dependent calls exhausts request workers. Chains including any asynchronous step should be background jobs by default.
How do AI agents chain API calls?
An agent is given a goal rather than a sequence. It makes a call, reads the result, and decides the next based on what came back, which is conditional chaining generated at runtime. Because the sequence is not fixed, error message quality becomes load-bearing: an agent receiving a bare 400 gives up, while one receiving a message naming the missing field corrects itself and retries.
What is an example of API chaining?
A common one is invoice processing: OCR a scanned PDF, extract structured fields from the text, validate the supplier's VAT number and IBAN, then summarise it for a ledger. Each step consumes the previous step's output. Other frequent chains are merchant verification (domain age, WHOIS, screenshot, VAT validation) and content pipelines (extract text, summarise, detect entities, translate).
Can I chain API calls without writing code?
Partly. Agents can chain calls at runtime when the endpoints are discoverable, which is what MCP provides. You describe the outcome and the agent selects and sequences the calls. For fixed, repeatable workflows a workflow engine or a short script is still more predictable.
How is API chaining different in 2026?
Two shifts. AI agents now assemble chains at runtime instead of executing a sequence written in advance, which makes the order non-deterministic and the cost variable. And chains have grown longer, because composing several existing capabilities is now cheaper than building one, so the failure modes that only appear at four or five steps deep are hit more often.
Can an AI agent chain API calls on its own?
Yes, provided it can discover what is available. Given a goal rather than a sequence, an agent calls something, reads the result, and picks the next call based on the output. This requires a discovery protocol such as MCP; without one the agent can only use tools handed to it up front, which is a fixed chain rather than a real one.
What makes chaining across different vendors harder?
Each vendor brings its own authentication, error format, rate limit, and quota. Quotas in particular do not pool, so exhausting one vendor's allowance stops the chain regardless of unused headroom elsewhere. A chain is only as available as its least-provisioned link.
11Sources
- What is API Orchestration, Kestra, on the distinction between orchestration and simple aggregation
- API Orchestration: Combining Multiple Services, API7, on chaining and aggregation as separate patterns
12About ApyHub
ApyHub is a curated API catalog for developers, teams, and AI agents, covering file conversion, data validation, AI and OCR, data extraction, domain intelligence, and more across 20 categories. One subscription covers the whole catalog, billed in atoms, with headroom pooled across every API rather than locked to individual services, which is what makes multi-step chains practical without provisioning each step separately.
Every service carries machine-readable certification covering data handling, retention, and standards alignment including GDPR, SOC 2, and ISO 27001. Every endpoint is MCP-ready by default, so agents can discover and chain them without hand-written wrappers.
ApyHub is headquartered in Amsterdam, with offices in the Netherlands, Greece, and India, and runs on EU infrastructure. The catalog holds 450+ services and 1,500+ endpoints, with new APIs and providers onboarded continuously. The free tier allows 5 calls a day with no credit card.
Publishing an API? Become a provider