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: Everbridge
providerId: everbridge
generated: '2026-08-27'
method: searched
source: https://developers.everbridge.net/home/docs/ebs-gs-guide-throttling-limits
modified: '2026-08-27'
# REPLACES the 2026-05-04 bulk-sweep scaffold, which asserted invented free/professional/
# enterprise tiers at 10/100/1000 requests per MINUTE. Everbridge's published limits are
# Bronze/Silver/Gold, expressed in requests per SECOND, with separate read and write rates
# and a daily quota. Nothing below is inferred.
tags:
- Critical Event Management
- Rate Limiting
- Throttling
- Quotas
description: >-
  Published Everbridge REST API throttling limits. Everbridge assigns every customer to a
  tier; all three tiers are free and moving up requires product-management approval rather
  than payment. All rate dimensions are requests per second. Exceeding a tier limit returns
  HTTP 429.
limit_count: 3
policy_statement: >-
  Everbridge reserves the right to limit excessive API requests to protect its infrastructure
  and maintain customer continuity against potential bad actors or incorrectly configured
  integrations.
tier_assignment:
  default_tier: Bronze
  upgrade_cost: none
  upgrade_process: >-
    Requests to move to a higher tier must be reviewed and approved by Everbridge product
    management.
  exclusions:
  - endpoints:
    - List /Incidents
    - /incidentNotification
    note: These requests are not eligible to move to a higher plan tier.
limits:
- tier: Bronze
  name: Bronze (default)
  scope: per-organization
  window: second
  read_limit: 10
  read_methods:
  - GET
  - DELETE
  write_limit: 20
  write_methods:
  - POST
  - PUT
  - PATCH
  burst_read: 25
  burst_write: 35
  daily_quota: 50000
  metric: requests_per_second
- tier: Silver
  name: Silver
  scope: per-organization
  window: second
  read_limit: 20
  read_methods:
  - GET
  - DELETE
  write_limit: 35
  write_methods:
  - POST
  - PUT
  - PATCH
  burst_read: 35
  burst_write: 50
  daily_quota: 100000
  metric: requests_per_second
- tier: Gold
  name: Gold
  scope: per-organization
  window: second
  read_limit: 35
  read_methods:
  - GET
  - DELETE
  write_limit: 50
  write_methods:
  - POST
  - PUT
  - PATCH
  burst_read: 50
  burst_write: 75
  daily_quota: 500000
  metric: requests_per_second
responseCodes:
  throttled: 429
  quotaExceeded: 429
headers:
  limit: null
  remaining: null
  reset: null
  retryAfter: null
  policy: null
  note: >-
    GAP — Everbridge documents no rate-limit response headers. Neither the throttling page
    nor any of the 13 harvested OpenAPI documents declares X-RateLimit-*, RateLimit-* or
    Retry-After on a 429 response, so an agent has no runtime signal for how much budget
    remains and must infer it from the 429 alone. The SnapComms API (api.snapcomms.com)
    declares a 429 "Failed - Rate limit is exceeded" response on 15 operations, also with
    no headers. This is the single most valuable rate-limit improvement Everbridge could make.
policies:
- name: Retry on 429
  description: >-
    Everbridge recommends retrying after 429 or any 5xx using exponential backoff with random
    jitter — sleep = random_between(0, min(cap, base * 2 ** attempt)) — continuing successive
    backoff for as long as calls fail, and resetting to the normal backoff threshold on the
    first 2xx.
  source: https://developers.everbridge.net/home/docs/ebs-gs-guide-throttling-limits
maintainers:
- FN: Kin Lane
  email: kin@apievangelist.com