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: Vibes Platform
providerId: vibes-platform
generated: '2026-08-13'
method: searched
source: https://developer-platform.vibes.com/reference/technical-details
docs: https://developer-platform.vibes.com/reference/technical-details
created: '2026-05-04'
modified: '2026-08-13'
tags:
  - Mobile Marketing
  - Mobile Messaging
  - SMS
  - MMS
  - Rate Limiting
  - Throttling
description: >-
  Published Vibes Platform API rate limits, read verbatim from the provider's Technical Details
  reference page on 2026-08-13. This replaces the 2026-05-04 scaffold that carried invented tier
  quotas. Limits are expressed as requests per second and are enforced per company_key or per
  app_id, not per plan tier.
limit_count: 4
enforcement: per-second throttle
exhaustion_status: 429
exhaustion_body: 'HTTP 429 Too Many Requests'
limits:
  - name: Inbound events
    scope: per-endpoint
    endpoint: POST /companies/{company_key}/events
    reference: https://developer-platform.vibes.com/reference/event-api
    limit: 300
    unit: requests
    window: 1s
    burst: null
  - name: All non-event API calls
    scope: per-account
    key: company_key
    limit: 100
    unit: requests
    window: 1s
    burst: null
  - name: Non-event API calls per mobile app
    scope: per-account
    key: app_id
    limit: 100
    unit: requests
    window: 1s
    burst: null
  - name: Google Wallet updates
    scope: per-endpoint
    limit: 20
    unit: requests
    window: 1s
    burst: null
headers:
  documented: false
  limit: null
  remaining: null
  reset: null
  retry_after: null
  note: >-
    Vibes documents the limits and the 429 status but publishes NO rate-limit response headers —
    no X-RateLimit-*, no RateLimit-*, no Retry-After. Nothing in the OpenAPI declares a response
    header on any operation either (75 operations, zero `headers` blocks). A client therefore has
    no runtime signal of remaining budget or reset time and can only back off reactively after a
    429. This is the single biggest agent-readiness gap on an otherwise well-documented API.
callback_side:
  note: >-
    Vibes also rate-limits in the other direction: its callback documentation warns that slow or
    heavy customer callback endpoints will trigger "rate limiting or other errors" and that a
    repeatedly failing URL can be put into a downed state that suspends delivery attempts.
  source: https://developer-platform.vibes.com/reference/callbacks