Instagram · Rate Limits

Instagram Rate Limits

Instagram Platform inherits Meta Graph API rate limiting. Two regimes apply - Platform Rate Limits (Graph API requests with app or user access tokens) and Business Use Case (BUC) Rate Limits (Marketing API, Instagram Platform, Pages API requests with system / page tokens). Standard endpoints are sized as "4800 * Number of Impressions" calls per 24-hour rolling window. Messaging and reply endpoints have specific per-second / per-account limits. Throttling decisions are surfaced via X-App-Usage and X-Business-Use-Case-Usage headers and via specific error codes.

Instagram Rate Limits is the machine-readable rate-limit profile for Instagram on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 6 rate-limit definitions, measuring requests_per_hour, requests_per_day, varies, and requests_per_second.

The profile also includes 4 backoff/retry policies defined and response codes documented for appRateLimitReached, userRateLimitReached, pageThrottled, instagramThrottled, messengerThrottled, throttled, and serviceUnavailable.

Tagged areas include Instagram, Meta, Social Media, and Rate Limiting.

6 Limits Throttle: 429
InstagramMetaSocial MediaRate Limiting

Limits

Platform Rate Limits (app token) app
requests_per_hour · hour
200 * Number of Users
Calls within one hour = 200 * Number of Users. X-App-Usage tracks call_count, total_cputime, and total_time as percentages; throttling engages when any reaches 100.
Standard endpoints (rolling window) app
requests_per_day · day
4800 * Number of Impressions
24-hour rolling window. Applies to standard Instagram Platform endpoints.
Business Discovery / Hashtag Search app
varies
separate Platform Rate Limits apply per Business Use Case
Conversations API messaging account
requests_per_second · second
2
Live replies account
requests_per_second · second
100
Post / reel replies account
requests_per_hour · hour
750

Policies

Backoff Strategy
When throttled, stop making calls (continued calls prolong recovery). Honor Retry-After and recheck X-App-Usage / X-Business-Use-Case-Usage before resuming.
Header-Driven Pacing
Read X-App-Usage and X-Business-Use-Case-Usage on every response and pace requests so call_count, total_cputime, and total_time stay below 100.
Filter Aggressively
Use field expansion sparingly and request only needed fields to reduce CPU-time consumption against the limit.
App Review Gating
Higher-throughput access (Advanced Access) requires Meta App Review and Business Verification rather than a paid tier upgrade.

Sources