Basecamp · Rate Limits

Basecamp Rate Limits

Basecamp's bc3-api enforces multiple rate limits simultaneously, scoped per IP address with separate windows for GET vs POST and per-second/hour/day buckets. The most commonly hit limit is 50 requests per 10-second window per IP. Thresholds are dynamic and not published per-plan; integrators must handle backpressure rather than rely on static numbers.

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

It captures 2 rate-limit definitions, measuring requests_per_10_seconds and varies.

The profile also includes 4 backoff/retry policies defined and response codes documented for throttled and serviceUnavailable.

Tagged areas include Collaboration, Project Management, REST, SaaS, and Team Communication.

2 Limits Throttle: 429
CollaborationProject ManagementRESTSaaSTeam CommunicationRate Limiting

Limits

Default per-IP throttle IP
requests_per_10_seconds · 10-seconds
50
Most commonly encountered limit. Multiple per-second/hour/day limits operate concurrently and are dynamically adjusted by Basecamp.
Per-method dynamic limits IP
varies
dynamic — separate buckets for GET and POST, per-second/hour/day
Documentation does not publish the exact thresholds; clients must observe 429 + Retry-After and back off.

Policies

Backoff Strategy
Implement exponential backoff with jitter and honor the Retry-After header on 429 responses.
Retry on 5xx
500, 502, 503, and 504 responses should be retried with exponential backoff. Do not retry 404s automatically.
Dynamic Backpressure
Basecamp explicitly warns thresholds adjust dynamically. Treat rate limits as observed runtime signals rather than static configuration.
User-Agent Identification
Basecamp requires a descriptive User-Agent header identifying the integration; missing/anonymous User-Agents may be blocked before rate limiting applies.

Sources