specification: API Commons Rate Limits
specificationVersion: '0.1'
schema: https://raw.githubusercontent.com/api-evangelist/interface-research/main/schema/api-commons.yml#/$defs/RateLimits
provider: Plunk
providerId: plunk
created: '2026-06-20'
modified: '2026-08-13'
generated: '2026-08-13'
method: searched
source: https://docs.useplunk.com/api-reference/overview
limit_count: 3
reconciled: true
tags:
- Email
- Transactional Email
- Marketing
- Automation
- Open Source
- SaaS
- Rate Limiting
- Quotas
- Throttling
description: >-
  The Plunk hosted API enforces a project-level rate limit of approximately
  1,000 requests per minute. Email sending is additionally throttled per project
  and bulk operations (such as large campaign sends) are automatically queued
  rather than rejected. Requests that exceed the limit return HTTP 429.
  Self-hosted deployments can configure their own limits.
notes: >-
  Re-verified 2026-08-13 against the Plunk API reference. The 1,000 req/min
  project limit is confirmed and stated exactly. The material finding on this
  pass is what is NOT published — see responseHeaders below.
sources:
- https://docs.useplunk.com/api-reference/overview
- https://docs.useplunk.com/api-reference/errors
- https://docs.useplunk.com/concepts/billing
- https://www.useplunk.com/pricing
responseCodes:
  throttled: 429
  throttledCode: RATE_LIMIT_EXCEEDED
  billingCapped: 402
  billingCappedCodes: [BILLING_LIMIT_EXCEEDED, UPGRADE_REQUIRED]
responseHeaders:
  published: []
  correlation: X-Request-ID
  note: >-
    GAP, and the most consequential one for agent use. Plunk documents the
    numeric limit but publishes NO runtime rate-limit response headers — no
    RateLimit-Limit/Remaining/Reset, no X-RateLimit-*, and no Retry-After on the
    429. The error reference tells callers to implement exponential backoff
    (1s, 2s, 4s, 8s) with no signal to base it on, so a client cannot read its
    remaining budget or the correct wait. The only header Plunk does return on
    every response, success or failure, is X-Request-ID for correlation.
  observed: probed
  observed_note: >-
    Unauthenticated probes of the API host root return the Plunk JSON 404
    envelope with no rate-limit headers; the documented limits could not be
    exercised anonymously, so this records what the docs publish plus what the
    error reference tells clients to do.
billingBackpressure:
  distinct_from_rate_limiting: true
  note: >-
    A separate throttle sits alongside the request rate limit: per-category
    monthly billing caps (Transactional, Campaigns, Workflows, Inbound). Hitting
    one returns 402 BILLING_LIMIT_EXCEEDED on outbound sends, while inbound mail
    is dropped silently for the project until the cap resets. A client that only
    handles 429 will misread 402 as a hard failure. See plans/plunk-plans-pricing.yml.
limits:
- name: Requests Per Minute
  scope: project
  metric: requests
  limit: ~1000 per minute
  notes: Project-level API request rate limit on the hosted platform.
- name: Email Sending Throttle
  scope: project
  metric: emails
  limit: throttled per project
  notes: Outbound send rate is throttled per project to protect deliverability.
- name: Bulk Operations
  scope: project
  metric: jobs
  limit: automatically queued
  notes: Large campaign and bulk operations are queued rather than rejected.
policies:
- name: Queuing
  description: Bulk sends and high-volume operations are queued and processed asynchronously instead of being rejected.
- name: Backoff Strategy
  description: Clients should implement exponential backoff with jitter and honor 429 responses.
- name: Self-Hosted Configuration
  description: Self-hosted deployments can configure their own rate limits and sending throughput.
maintainers:
- FN: Kin Lane
  email: kin@apievangelist.com