Help Scout ties API rate limits directly to the pricing plan

The workload

Help Scout's own developer documentation states that building an integration against its Mailbox API means designing around a per-plan request ceiling rather than a fixed number available to every account. Verified: the rate-limiting page states that the API is rate limited per account (all users on an account share one limit), that PUT and PATCH requests each count as 2 requests toward that limit, and that a 429 response is returned once the limit is reached. Verified: the linked plan-access article states the actual numbers depend on the Help Scout plan: up to 200 calls per minute on Standard, 400 on Plus and 800 on Pro, and that the Free plan has no API access at all.

What the documents show

Verified: the rate-limiting page names three response headers a client should read — X-RateLimit-Limit-Minute, X-RateLimit-Remaining-Minute and X-RateLimit-Retry-After — the last of which states how many seconds to wait before retrying after a 429. Verified: the plan-access article states that the Standard plan additionally lacks access to reporting endpoints, a restriction separate from its lower call limit, so upgrading from Standard to Plus changes both the ceiling and which endpoints are reachable at all. On webhook delivery specifically, the webhook creation documentation states that each webhook is assigned a secret used to generate a signature the receiving server can verify, but the pages retrieved for this entry do not state a specific retry count, backoff schedule or delivery-guarantee figure for failed webhook deliveries; this entry does not assert one because the documentation does not supply it.

The operating cost

There is no separate fee for API access beyond the plan price itself; the cost is the plan tier required to reach a given rate limit — $25, $45 or $75 per user per month for Standard, Plus or Pro respectively, per Help Scout's pricing page, with the higher tiers buying a higher requests-per-minute ceiling as well as broader endpoint access, as the documentation states it.

The stop condition

The documentation does not claim the API suits any particular integration pattern, and this entry does not extend that claim either. Editorially, the point to stop and reconsider architecture is a sustained pattern of 429 responses despite honoring the Retry-After header, since that indicates the integration's request volume has outgrown the account's plan-based ceiling rather than being a transient burst; the fix the documents point to is a plan upgrade or a redesign that uses fewer, larger requests (since PUT and PATCH already cost double) rather than retry logic alone.

• Does the integration's expected call volume fit within the current plan's per-minute ceiling, accounting for PUT and PATCH counting double?
• Does the integration need reporting endpoints, which the documentation says the Standard plan does not include?
• Is webhook signature verification implemented, given that the documentation does not separately guarantee delivery retries?

The documentation ties API capacity directly to the pricing plan and states the mechanics of signing and rate-limit headers clearly, while leaving webhook retry behavior undocumented in the pages retrieved, a gap worth designing around rather than assuming away.