What we learned building 100 API integrations with OpenCode

At Nango, we build open source infrastructure for product integrations.

With all the recent advancements in coding models, we wanted to see how far we can push an autonomous agent building integrations with external APIs.

TL;DR: Our background agent isn’t perfect, but it reliably generates ~200 integrations across five APIs (Google Calendar, Drive, Sheets, HubSpot, and Slack) in 15 minutes and less than $20 in token costs.

Previously, this would have taken an engineer about a week.

This post is about what it took to get there, what broke along the way, and what we learned building a background coding agent for API integrations.

Our setup

The pipeline is pretty simple:

• We define a list of interactions to build, for example create-calendar-event, sync-files, or send-slack-message.
• Our orchestrator prepares one workspace per interaction with the right Nango integrations scaffolding generated by our CLI.
• We spawn one OpenCode agent per interaction.
• Each agent independently builds its interaction, tests it with the external API (the agent has access to a test account), and iterates until it works.
• Once all agents finish, the orchestrator checks their work and assembles the individual interactions into one Nango integration per API.

Note that we only gave the agent very high-level instructions (“create a calendar event”), and it autonomously researched required parameters, formats, and descriptions.

1. Let the agents run wild first

We chose to start with very few guardrails to learn what the models actually do. We didn’t want to overfit our assumptions.

Some of it went better than expected. Agents often filled in gaps in our instructions, inferred how to use existing SDK helpers, and required a lot less handholding than we expected. But they also broke in very unexpected ways.

2. Do not trust the agents

Agents optimize for completion at all costs. Here are some of the behaviours we saw:

Copying test data from other agents

One agent looked through another agent's directory and reused an event ID it found there instead of creating its own. Fix: Agents are no longer allowed to leave their own directory.

Hallucinating a Nango CLI command

Some hallucinated commands were plausible, but the agent often got stubborn when a command failed, going down a rabbit hole trying to make a non-existent command work. Fix: Improve instructions around the available API and CLI.

Editing test data when the implementation failed

Changing the test data was easier than fixing the code, so that is what some agents tried to do when their implementation failed. Fix: Tighter edit permissions and explicit checks that test fixtures were not modified.

Faking API reachability

Instead of flagging an auth problem, the agent sometimes decided to keep going by writing the response it thought the API would probably return. Fix: Prevent the agent from modifying test data and make failed API access a hard stop.

Claiming it is done when it is not done

The agent writes a clean summary but leaves behind code that does not compile or pass tests. Fix: Delete the agent, restart generation for this interaction from scratch.

3. Ignore the final error message and trace the root cause

When a run failed, the final error reported by the agent was often a red herring. A common pattern involved the agent hallucinating a command, misreading the failure, and building a workaround on top of a wrong assumption.

If you only debug from the final error, you often end up debugging the wrong thing. OpenCode makes inspection easy because all messages are stored in a SQLite database, allowing us to automate checks and inspect traces.

The main takeaway: do not trust the agent. Verify everything.