ShootProof · Rate Limits

Shootproof Rate Limits

ShootProof's public Studio API guide (Guide > Errors) documents 400, 409, and 507 (Insufficient Storage - a plan-capacity error, not a rate-limit error) as its notable status codes, but does not publish a numeric requests-per-second/minute rate limit, a 429 Too Many Requests convention, or documented `Retry-After`/rate-limit response headers as of the review date. Access tokens are Bearer tokens issued via three-legged OAuth 2.0 and are valid for two weeks (1,209,600 seconds); refresh tokens are used to obtain new access tokens without user interaction.

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

It captures 4 rate-limit definitions, measuring requests, seconds, photos_and_bytes, and items.

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

Tagged areas include Photography, Client Galleries, Rate Limiting, and Quotas.

4 Limits Throttle: not published
PhotographyClient GalleriesRate LimitingQuotas

Limits

Studio API Requests account
requests
not published
No fixed numeric request-rate limit is documented for the Studio API.
Access Token Lifetime token
seconds
1209600
OAuth 2.0 access tokens last two weeks (14 days); refresh tokens obtain new access tokens thereafter.
Storage / Active Photo Capacity account
photos_and_bytes
per subscription plan
Exceeding a plan's active-photo/storage allowance returns HTTP 507 Insufficient Storage rather than a rate-limit error.
Batch Operation Size request
items
not published per call, but batch endpoints exist for events/albums/photos/price-sheet items/groups
Batch PATCH/DELETE endpoints let clients update or remove many resources in a single call instead of looping per-item requests.

Policies

Backoff Strategy
Not formally documented; standard practice is exponential backoff with jitter on 5xx responses and re-authentication on 401.
Token Rotation
Access and refresh tokens must be treated like a user's password and encrypted at rest per the Authorization guide.

Sources