Articles

Instantly API: Build Your Own Integration or Let an Agent Handle It

Ibby SyedIbby Syed, Founder, Cotera
9 min readMarch 7, 2026

Instantly API: Build Your Own Integration or Let an Agent Handle It

Instantly API: Build Your Own Integration or Let an Agent Handle It

Tomás spent three weeks building a custom Instantly integration. He's a decent engineer — not a backend specialist, but comfortable with APIs and Node.js. The goal was simple: pull campaign analytics from Instantly every morning, cross-reference with our CRM data, and generate a report showing which campaigns were producing pipeline and which were burning leads.

On week one, he had authentication working and could pull basic campaign data. On week two, he was fighting with pagination and discovering that some response fields weren't in the documentation. On week three, he was debugging a rate limit issue that only appeared when pulling lead-level data across more than ten campaigns simultaneously.

He got it working. The integration ran for about six weeks before a response format change in one endpoint broke the analytics pipeline. Tomás fixed it in an afternoon, but during those hours the morning report didn't generate, and Kenji made three decisions about campaign pausing based on stale data.

This is the build-vs-buy story, except in this case "buy" means letting an AI agent handle the API so you don't have to.

What the Instantly API Actually Offers

The API covers four main areas: campaigns, leads, analytics, and account management.

For campaigns, you can list all campaigns, get details on a specific campaign, create new campaigns, update campaign settings, and change campaign status (launch, pause, complete). The campaign endpoints are the most stable and best-documented part of the API. Tomás had zero issues with them.

Lead management lets you add leads to campaigns, list leads with filtering, update lead status, and delete leads. This is where the API starts to get interesting and also where it starts to get tricky. Adding leads in bulk works, but the endpoint has a payload size limit that isn't prominently documented. Tomás hit it when trying to load 2,000 leads at once and had to implement batching logic (chunks of 500 worked reliably).

Analytics endpoints return campaign-level metrics: sent count, open rate, reply rate, bounce rate, click rate. You can get these at the aggregate level or filtered by date range. The data matches what you see in the Instantly dashboard, which is reassuring but also means the API has the same limitation as the dashboard — campaign-level granularity only. You can't easily get step-level performance (which email in a four-step sequence generated the most replies) through the API alone.

Account management covers mailbox health, warmup status, and sending limits. This is useful for monitoring infrastructure health programmatically.

Authentication is API key-based. You get one key per workspace. It goes in the request header. No OAuth flow, no token refresh. Straightforward.

The Hard Parts

Rate limits are where most custom integrations run into trouble. Instantly's API allows a reasonable number of requests per minute for normal operations, but "normal operations" and "pulling analytics across 20 campaigns with lead-level detail" are different things. Tomás implemented exponential backoff after getting rate-limited three times during development.

Pagination is standard but has a quirk. The API returns paginated results with a cursor-based system. The quirk is that some endpoints return different page sizes depending on the query complexity. Tomás expected consistent 100-item pages and got anywhere from 50 to 100 depending on the filters applied. He had to rewrite his pagination logic to handle variable page sizes gracefully.

Response format consistency is the biggest pain point. Most endpoints return predictable JSON structures. But Tomás found at least two cases where the field naming was inconsistent between the list endpoint and the detail endpoint for the same resource. A field called email_account in one response was called sending_account in another. Small things, but they add up when you're writing parsing logic.

Error handling is minimal. The API returns standard HTTP status codes (200, 400, 401, 429, 500) but the error bodies don't always tell you what went wrong. A 400 error might mean bad input, missing required field, or invalid filter combination. Tomás spent an afternoon debugging a 400 that turned out to be a date format issue (the API wanted epoch timestamps, not ISO strings, for one specific endpoint).

What Tomás Built

The finished integration did three things:

It pulled campaign metrics daily and stored them in a Postgres database so we could track trends over time. Instantly's dashboard shows you current metrics but doesn't make it easy to see how a campaign's open rate has changed over 30 days.

It cross-referenced active leads in Instantly with deals in our CRM (HubSpot) to flag cases where we were cold emailing someone who was already in an active sales conversation. This happened more than we expected — about 2% of leads in Instantly had an open deal in HubSpot. Cold emailing someone your AE is actively negotiating with is a bad look.

It generated a morning Slack report with campaign health metrics, sorted by which campaigns needed attention.

Total development time: roughly 60 hours spread over three weeks. Maintenance over the following six months: about 12 hours, mostly dealing with the response format change and two minor bugs.

The Agent Alternative

After Tomás's integration broke for the second time, Priya asked a reasonable question: "Could an agent just do this?"

We set up a LinkedIn personalized sequences agent alongside a campaign monitoring agent and pointed them at the same Instantly workspace. The monitoring agent replicates what Tomás built: daily campaign analytics, trend tracking, anomaly detection. The LinkedIn agent adds something Tomás's integration didn't have — the ability to coordinate Instantly email sequences with LinkedIn outreach based on campaign data.

The agent took about two hours to configure. Not three weeks. Two hours. It handles the API pagination, rate limiting, and response parsing without anyone writing custom code. When a response format changes, the agent adapts because it's interpreting the API responses rather than parsing them against a rigid schema.

In the four months since, the agent has required zero maintenance. Tomás's integration required 12 hours of maintenance in a comparable period. That's not a knock on Tomás — he built a solid integration. It's a reflection of the difference between brittle code that expects specific response shapes and an agent that understands what the response means regardless of exact formatting.

Honest Trade-offs

The agent approach has real limitations that I'd be dishonest to skip.

Control. Tomás's custom integration did exactly what he programmed it to do, nothing more and nothing less. He controlled the logic, the edge cases, the output format. The agent handles edge cases well, but "well" is probabilistic, not deterministic. In six months of running, the agent has never made an error in campaign monitoring. But I can't prove it won't, the way Tomás can prove his code handles a specific edge case.

Data storage. Tomás's integration writes to a Postgres database, which means we have raw historical data we can query however we want. The agent generates reports but doesn't maintain a queryable historical database. If we want to run a custom analysis on six months of campaign data, Tomás's database is more useful.

Customization depth. Tomás's CRM cross-reference was specific to our HubSpot setup: specific deal stages, specific field mappings, specific logic about what constitutes a "conflict." The agent can do CRM cross-referencing, but getting it to match Tomás's exact logic required careful prompting. It got there, but it wasn't instant.

Speed of iteration. When we wanted to add a new metric to the morning report, Tomás could add it in 20 minutes. Adjusting the agent's report format takes about 5 minutes of changing the instructions. The agent wins here, clearly.

Reliability. The custom integration failed twice in six months due to API changes. The agent has failed zero times. For ongoing operations, this matters more than the theoretical control advantage.

When to Build Custom

Build a custom integration if you need a persistent, queryable data warehouse of Instantly metrics. If your analytics team wants to run SQL queries against six months of campaign data, an agent-generated daily report won't cut it.

Build custom if you have very specific, logic-heavy workflows that involve multiple conditional branches. If "add lead to Instantly only if they're not in HubSpot, haven't been contacted in 90 days, match ICP criteria A but not B, and their company has raised funding in the last 18 months" is your actual workflow, custom code might express this more reliably than agent instructions.

Build custom if your engineering team has the capacity and you want total control over every data flow.

When to Use an Agent

Use an agent if you want monitoring, reporting, and campaign management working this week instead of next month. The setup-to-value time difference between "two hours" and "three weeks" is not trivial when your campaigns are running right now and nobody's watching them.

Use an agent if your team doesn't have an engineer who can spend 60 hours on an API integration. Most SDR teams don't.

Use an agent if you want the system to adapt when the API changes, instead of breaking and waiting for someone to fix it.

Use an agent if you want intelligence, not just data. The agent doesn't just pull numbers. It interprets them, spots patterns, and makes recommendations. A custom integration gives you a dashboard. An agent gives you an analyst.

Tomás, for the record, now uses the agent for daily monitoring and keeps his custom integration running for the historical database. He calls it "belt and suspenders." I call it a good engineer who knows when to write code and when not to.


Try These Agents

For people who think busywork is boring

Build your first agent in minutes with no complex engineering, just typing out instructions.