The Instantly.ai API: Rate Limits, Scopes, and What You Can Automate

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 actually do, where it constrains you, and the parts worth designing around. All from Instantly's own developer documentation, fetched 11 August 2026.

Authentication and scopes

Authentication is a bearer token. Add an authorization header with the value Bearer followed by your API key.

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.

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

100Requests per second

The burst ceiling, easy to hit with unthrottled parallelism

6,000Requests per minute

Averages to 100 a second, so sustained bursts exhaust it

1Workspace, not per key

Shared across v1 and v2 and across every key you issue

Exceeding either returns 429.

Note how the two interact. Six thousand a minute averages exactly to 100 a second, so the per-minute limit is not headroom above the per-second one; it means you cannot burst at the ceiling and sustain it. A job running flat out at 100 requests a second exhausts the minute allowance in sixty seconds and then stops. Design for a sustained rate comfortably below both.

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.

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.

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.

1. Step 1Call the endpoint

   You get a background job object back immediately, not a completed result.

2. Step 2Persist the job ID

   Store it before doing anything else. A job ID held only in memory is lost to any restart.

3. Step 3Poll with backoff

   Query the background-jobs endpoint on an interval that widens, since polling tightly spends your rate limit on waiting.

4. Step 4Reconcile against live state

   When the job reports done, re-read the accounts themselves. The job status describes the job, not the accounts.

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. 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 a platform that does not publish its limits, 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.

Authentication, scopes, rate limits, background-job behaviour, bulk-pause semantics and the documented endpoint surface are per Instantly's developer documentation, fetched 11 August 2026. Google sender requirements are per Google's published guidelines, same date. Verify current API behaviour with Instantly before building.

Sources: Instantly API rate limits, Instantly API authorization, Google email sender guidelines