The Instantly.ai API: Rate Limits, Scopes and Automation

Instantly publishes its rate limits, which sounds like a small thing until you try to capacity-plan against a competitor that does not. The numbers are 100 requests per second and 6,000 per minute, and the important detail is what they apply to: the entire workspace, shared between API v1 and v2, regardless of how many API keys you have issued.

That last clause defeats the obvious workaround. Minting a second key to double your throughput does nothing, because the limit is not per key. Here is what the API can do, including how to list emails and replies now that API v1 is deprecated, where it constrains you, and the parts worth designing around, all from Instantly's own developer documentation.

Instantly.ai API v1: Listing Emails and Replies

API v1 is deprecated. Instantly's migration guide says it was deprecated on January 19, 2026 and that new integrations should use API v2, though v1 integrations such as Zapier and Make keep working. The v1 call GET /unibox/emails/list maps to GET /api/v2/emails, replies are that list filtered to email_type=received, and POST /unibox/reply becomes POST /api/v2/emails/reply.

1

List emails. GET /unibox/emails/list becomes GET /api/v2/emails, a list with filtering.

2

Count unread. GET /unibox/emails/unread/count becomes GET /api/v2/emails/unread/count.

3

Reply. POST /unibox/reply becomes POST /api/v2/emails/reply, with reply_to_uuid in the body.

The v2 list endpoint is where the detail lives, and one line at the top of its reference changes how you build on it: it has a rate limit of 20 requests a minute, unlike other API endpoints. Everything visible in the Unibox comes back from it, campaign emails, replies and manually sent emails alike, so the filters do the work. email_type takes received, sent or manual; campaign_id, lead, eaccount and is_unread narrow the set; min_timestamp_created and max_timestamp_created bound it in time; latest_of_thread returns only the newest email in each thread; and a search of thread: followed by a thread ID pulls one conversation. Marking a thread read moves from POST /unibox/threads/mark-read to POST /api/v2/emails/threads/{thread_id}/mark-as-read. Pages hold up to 100 emails, and starting_after takes the next_starting_after value from the previous response. The key needs emails:read, emails:all, all:read or all:all.

Answering a reply is its own call. POST /api/v2/emails/reply sends only as a reply to an existing email, and it requires reply_to_uuid, the id of the email being answered, plus eaccount, subject and body, with an emails:create or wider scope.

At 20 list requests a minute, polling for replies is the expensive way to watch an inbox. Instantly's webhook events include reply_received and auto_reply_received, which push the event to you instead, and that is the better fit for anything that has to react quickly.

Poll the list

• GET /api/v2/emails with email_type=received
• 20 requests a minute on this endpoint
• Up to 100 emails a page, paged with starting_after
• Narrow with campaign_id, is_unread or min_timestamp_created

Subscribe to events

• reply_received: a reply was received from a lead
• auto_reply_received: an auto-reply was received
• Pushed to your endpoint, so no list calls are spent waiting

Authentication and scopes

Authentication is a bearer token. Add an authorization header with the value Bearer followed by your API key, and send API v2 requests to https://api.instantly.ai/api/v2.

The more interesting part is that v2 keys are scoped. Endpoints declare the scopes they require, in the shape accounts:read, accounts:create, accounts:update, accounts:delete or accounts:all, with wildcard equivalents like all:read and all:all covering everything.

The documentation's own advice is to select only the scopes your integration requires, and that granularity is worth using rather than defaulting to all:all. A key that only reads analytics cannot pause your mailboxes if it leaks, and a reporting integration has no business holding delete permissions. Issue one key per integration, scoped to what that integration genuinely does, and the blast radius of a compromised key becomes a design decision rather than an accident.

The rate limits, precisely

Exceeding either returns 429.

Note how the two interact. Six thousand a minute averages exactly to 100 a second, so the per-minute limit adds no headroom above the per-second one: a job that runs at the per-second ceiling has no slack left in the minute, and one burst of retries tips it over. Design for a sustained rate comfortably below both. Some endpoints also carry a tighter limit of their own: List email allows 20 requests a minute, and Send a test email 10 a minute per workspace.

Instantly's own documented mitigations are sensible and worth following. Run automations two to four times a day rather than once, so a single run is not trying to push a day's worth of requests at once. And batch: its documentation gives the worked example of updating 10,000 leads by batching 100 at a time with a 2-second wait between batches.

The workspace-level scope has an organisational consequence too. If several integrations share a workspace, they share the limit, and one badly behaved job starves the others. On a shared workspace, self-throttling is not politeness, it is the only thing preventing your reporting job from being blocked by somebody else's bulk update.

What you can automate

The v2 surface is broad. The parts that matter most for outbound operations:

Email account management. List, create, get, patch and delete accounts. Pause a single account, or pause up to 100 accounts in one call, with the response separating paused_emails from failed_emails so you can see exactly which ones did not take.

Warmup control. Enable and disable warmup for accounts programmatically, and pull warmup analytics. Both enable and disable are asynchronous: they start a background job and return the job object, and you poll GET /api/v2/background-jobs/:id to watch it complete.

The InboxAlly vs Instantly comparison explains why warmup and outreach execution are treated as separate workflow stages rather than as competing platforms.

The Gong vs Instantly comparison explains why deal intelligence platforms and cold email execution tools occupy separate stages of the revenue workflow rather than competing directly.

Analytics. Daily account analytics showing emails sent per day per account, which is the endpoint to build volume monitoring on.

Campaign and lead operations, plus account-to-campaign mapping so you can ask which campaigns a given mailbox is attached to.

OAuth connection flow for programmatically connecting Google and Microsoft accounts to a workspace, which is the piece that makes provisioning a mailbox estate scriptable rather than manual.

Deciding where a connected account actually stores its data matters well beyond Instantly, and Pipedrive's document storage setup shows how tying documents to Drive or SharePoint changes sharing and versioning.

Workspace groups, for managing multiple sub-workspaces from a single admin workspace. That is the agency feature.

The asynchronous pattern is the one to get right

Several operations do not complete inside the request. Warmup enable and disable are the documented examples: you receive a background job object and poll for its progress.

That fourth step is the one worth insisting on. A completed background job tells you the job finished, which is not the same claim as every account now being in the state you asked for. Re-reading the accounts costs one call and converts an assumption into a fact, and it is the same discipline the bulk-pause endpoint enforces on you by returning failed_emails separately.

Monitoring worth building alongside it

The daily account analytics endpoint returns emails sent per day per account, and it is the most useful monitoring primitive in the API.

Two alerts are worth building on it. A mailbox sending materially more than its intended daily cap means a configuration has drifted or a campaign is distributing unevenly, and per-mailbox volume spikes are exactly what reputation systems respond to. A mailbox sending zero when it should be sending is the quieter failure: an account can disconnect, hit an authentication error or be paused without anything announcing it, and an estate of 50 mailboxes can lose several without the aggregate numbers moving enough to notice.

That second case is the one that justifies the endpoint. Aggregate send volume looks healthy while individual mailboxes fall out of rotation, because the remaining mailboxes absorb the load and quietly send more than they should. One failure produces two problems, and only per-account data shows either of them.

What the API will not do for you

Worth stating plainly, because API capability gets confused with operational safety.

It will not protect your domains. You can script the provisioning of 200 mailboxes, enable warmup on all of them and launch tomorrow, and every one of those calls will succeed. Whether that is survivable depends on domain authentication, list quality and pacing, none of which the API evaluates. Google's published requirements are the actual bar: SPF or DKIM for all senders, valid forward and reverse DNS, TLS, spam rates in Postmaster Tools below 0.30%, and SPF, DKIM and DMARC together above 5,000 messages a day to Gmail.

It will not tell you a job stalled. A rate-limited worker retrying with backoff and a worker with nothing left to do look identical from outside. Report sustained 429s explicitly rather than letting backoff swallow them.

It will not make sequencing safe. The API can add steps to a campaign as easily as one. We run one message per campaign and do not send thread follow-ups, which is a house position rather than a platform constraint: a follow-up increases volume against the same list without improving targeting, and volume against unimproved targeting is what moves complaint rates.

Designing around a shared workspace budget

The workspace-level limit has an organisational consequence that catches teams as they grow, and it is worth designing for before it bites.

Every integration touching the workspace draws from the same 100-per-second and 6,000-per-minute allowance. A reporting job, a CRM sync, a lead-loading pipeline and an ad-hoc script all compete, and none of them can see the others' consumption. The failure is asymmetric: a bulk job running flat out does not fail, it simply starves everything else, and the thing that breaks is the small, latency-sensitive integration that only needed a handful of calls.

Three habits keep it workable. Give every integration its own self-imposed ceiling, well below the workspace limit, so no single job can consume the whole budget even when it has a large queue. Run bulk work on a schedule rather than on demand, at hours when the interactive integrations are idle. And make each integration log its own request volume, because when the workspace starts returning 429s you need to know which job is responsible, and the platform will not tell you.

The same reasoning applies to the v1 and v2 sharing. Two versions drawing from one budget means a partial migration doubles your request count against an unchanged allowance, at exactly the moment when both paths are active.

Migrating from v1

Instantly publishes a v1-to-v2 migration guide with endpoint mapping, which is the document to read first if you have an existing integration. It records v1 as deprecated, says to use v2 for all new integrations, and says integrations using v1, like Zapier and Make, keep working. The rate limit is shared between the two versions, so a partial migration running both concurrently draws from one budget rather than two, and a migration window is exactly when request volume is highest.

For the product around the API, the Instantly review covers the plans and inclusions, and the pricing breakdown covers what caps you at each tier. For the comparison on automation surfaces specifically, the Smartlead API guide covers the same questions for Smartlead's API, and migrating between tools covers moving an estate without losing reputation.

We build and operate this kind of integration for clients on a pay-per-qualified-meeting basis. You can see what a campaign would look like for your market.

Pricing and features are taken from the vendors' own pages. Verify current terms with the vendor before relying on them.

Sources: Instantly API rate limits, Instantly API authorization, API v1 to v2 migration, List email, Webhook events, Google email sender guidelines