Custom API integration
Legacy APIs weren’t built for agents, and neither was your integration layer.
The vendor API your workflow depends on has years of versions, a spec that does not match its behaviour, and sequences nobody documented. The usual answer is to build a custom integration around it. That works, once. Then the API changes.
There are three real alternatives to building custom API integrations for an AI agent: build and maintain them in-house, use a general tool-catalog layer, or use a production execution layer. This page explains what each one actually costs you and when each is the right call.
Use the LLM your team prefers. Start free with MCP and CLI—without a separate SDK for every service.
The commitment
What a custom API integration really commits you to
Writing the first call is the easy part. A custom API integration is a standing commitment to five things, per API, forever.
Authentication
Token acquisition, refresh, rotation, and keeping credentials out of agent code and prompts.
Retries that are safe to run
A retry without idempotency turns one intended action into two real ones. Getting this right per endpoint is its own project.
Schema and response validation
The payload going out has to match the live contract, not the one a model learned in training. The response coming back has to be read properly, because a 200 with an error in the body is a failure your agent will log as a success.
Policy
Which calls are allowed to run, in which environment, against which records.
Audit
A record of what ran, so a failure can be reconstructed.
None of this is interesting work, and all of it is load-bearing. The cost is not the build. It is that every one of these has to be maintained per API, and rechecked every time the vendor changes something without telling you.
The options
The three alternatives, honestly
Option 1—Build it in-house
Makes sense when you have one or two APIs, they are stable and well-documented, and your team wants total control of the execution path. The real cost is the five commitments above, multiplied by every API, carried indefinitely. It breaks at the third or fourth API, and immediately on any API old enough to have accumulated versions and undocumented behaviour.
Option 2—A tool-catalog layer
Makes sense when your agent needs broad reach across many modern SaaS APIs with clean, current specs and straightforward OAuth. What it gives you is connectivity. Ask what happens on a retry, whether the response body is validated or only the status code, whether there is an allowlist, and whether anything is recorded. Catalog breadth does not answer any of those.
Option 3—A production execution layer
Makes sense when the agent has to complete real business workflows against systems you do not own, and a wrong or duplicated action has consequences. It gives you the correct path for a given workflow, plus authentication, retries with idempotency, schema and response validation, policy enforcement, and an audit record—as the default behaviour rather than as code you wrote. This is what Swytchcode is.
Choosing
How to choose
| Your situation | Reasonable choice |
|---|---|
| One or two stable, well-documented APIs | Build in-house |
| Broad reach across modern SaaS APIs, low-consequence actions | Tool-catalog layer |
| Older vendor APIs, or actions with real consequences | Production execution layer |
| Multiple APIs and a team that does not want to own auth and retry logic per service | Production execution layer |
The mechanism
Where the implementation knowledge comes from
- 01
Ingest
The API’s specification, SDKs, and documentation.
- 02
Correct
Published specs are frequently wrong, so they are reconciled against how the API actually behaves.
- 03
Codify
Every failure encountered gets fixed permanently. The next team never hits it.
- 04
Compile
The result becomes a manifest—a condensed, corrected contract paired with the documentation knowledge the vendor never published.
- 05
Serve
The agent receives the exact methods its workflow needs through MCP, rather than the entire API surface.
FAQ