Exact values

API limits and webhooks

Reference Reviewed · not yet fact-checked

In short

What are Reply's API rate limits and how do webhooks work?

Reply's API allows 15,000 calls every 30 calendar days per team member — limits are not shared — with a 10-second minimum between calls. Zapier calls count; native integrations do not. Webhooks come in two generations: legacy V2, configured with an API key, and current V3, managed in Settings or via the web API.

This page covers what the API reference itself does not state: limit semantics and the two webhook generations. For endpoints, authentication, and schemas, docs.reply.io is the source of truth.

Rate limits

Limit	Value
API calls	15,000 every 30 calendar days
Minimum interval between calls	10 seconds
Scope	Per team member — in team accounts, limits are not shared; each member has their own 15,000 calls per month
Counts against the quota	Reply's Public API and Zapier integrations
Does not count	Calls from native integrations
Contact sync via integrations	Same limit as prospects

Usage is shown on the Plans & Billing page, under User shared add-ons, in the API limit counter. Reply's documentation describes the quota as covering every 30 calendar days and separately states that the limit resets on the first of each month — it does not reconcile the two statements. What happens to requests once the quota is exhausted is not documented; to get a higher limit, contact Reply support through the product interface. General product limits (sending, contacts, LinkedIn) are on Limits.

Webhook generations

Webhooks send real-time data to your endpoint when an event occurs; each notification includes the event type and the data related to it.

Generation	Status	Managed via	Auth
V3	Current	The Webhooks UI in Settings and the `/webhook-subscriptions` web API	Cookie session plus an `x-xsrf-token` header on write requests
V2	Legacy	The public API	API key

Users with active V2 webhooks can view them in a read-only info panel in the V3 UI; V2 subscriptions cannot be created or edited through V3 endpoints, and V3 subscriptions never appear in the legacy listing.

Webhook event types

Category	Events
Email	`email_sent`, `email_opened`, `email_link_clicked`, `email_replied`, `contact_replied`, `reply_categorized`, `email_bounced`, `contact_opted_out`, `contact_finished`, `contact_called`, `email_account_connection_lost`, `email_account_error`
LinkedIn	`linkedin_connection_request_sent`, `linkedin_message_sent`, `linkedin_connection_request_accepted`, `linkedin_message_replied`, `linkedin_reply_categorized`, `linkedin_account_alerts`
Other	`autopilot_stopped` — fires on the first stop and includes the reason

Behavior that differs between generations:

Event	V2 (legacy)	V3 (current)
`email_replied`	Fires once, on the first reply / when the status is set to Replied	Fires on every stored reply, including direct follow-up replies; direct replies have no sequence context, so `sent_email_id` and `sequence_fields` are omitted
`contact_replied`	Not available	V3 only — fires when a contact's status becomes Replied, currently for email-detected replies and manual or API "mark as replied"; LinkedIn and SMS replies do not trigger it yet

V3 subscription model

Scope	Availability
`personal`	Always allowed — visible only to the creating user
`team`	Public/Organization team members and Private-team owners; solo users receive `403`
`organization`	Reserved — always returns `400` (not yet implemented)

Payload options, all defaulting to false: includeEmailUrl and includeEmailText (email events), includeLinkedInMessageText (linkedin_reply_categorized — currently API-only, with no checkbox in the Webhooks UI), and includeProspectCustomFields (all events).

Payload details worth knowing before parsing:

Sequence-linked events carry a sequence_fields object with the sequence id and name (resolved server-side); step_number is included except on contact_finished and linkedin_connection_request_sent, which fire at the sequence level.
reply_categorized always includes reply_subject; linkedin_reply_categorized includes inmail_subject only when the reply is an InMail — regular LinkedIn messages have no subject, so the field is omitted rather than sent empty.
email_replied (V3) and contact_replied include reply_reason: EmailDetected or StatusSetManually.
A subscription's enabled flag is toggled only through the dedicated /enable and /disable endpoints — a PUT on the subscription does not accept it.
The subscription API uses a flat eventType field, while delivery payloads nest the type as event.type inside an event envelope.

Not yet implemented in V3: server-side list filtering, bulk enable/disable/delete, the organization scope, and a pagination envelope on delivery logs (a bare array is returned).

FAQ

No. In team accounts each team member has their own allocation of 15,000 calls per month — limits are not shared between members.

What happens when the quota runs out?

Reply's documentation does not specify how over-quota requests are handled. Check your usage on the Plans & Billing page and, if you need more, request a higher limit from Reply support through the product interface before you hit it.

Can I still use V2 webhooks?

Existing active V2 subscriptions keep working and are visible read-only in the V3 UI, but they cannot be created or edited through the V3 endpoints. New subscriptions are made as V3, in Settings → Webhooks or via the /webhook-subscriptions API.

Build with Reply

REST API: docs.reply.io — endpoints, authentication, and schemas
MCP: agents.reply.io/mcp — an alternative surface for agents that avoids polling the REST API