Prolific · Rate Limits

Prolific Research Rate Limits

Prolific does not publish fixed numeric per-second or per-minute request limits for its API. Instead, limits are implicit and arise from contention on shared resources - primarily the workspace wallet. Payment operations (submission approvals and bonus payments) are the most prone to 429 Too Many Requests responses because they verify and debit the shared balance concurrently. The Studies API additionally applies rate limits designed to prevent researchers from launching too many studies with very low participant counts. Prolific recommends keeping concurrent active studies under roughly 100 per workspace.

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

It captures 5 rate-limit definitions, measuring requests, studies, and participants.

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

Tagged areas include Research, Participant Recruitment, Rate Limiting, and Quotas.

5 Limits Throttle: 429
ResearchParticipant RecruitmentRate LimitingQuotas

Limits

General API Requests account
requests
not published (implicit, resource-contention based)
No fixed numeric request-rate limit; throttling arises from shared-resource contention.
Wallet / Payment Operations workspace
requests
implicit
Approvals and bonus payments contend on the workspace wallet and are the most likely to receive 429.
Study Launches account
studies
rate-limited for low-participant studies
The Studies API limits launching many studies with low numbers of participants.
Concurrent Active Studies workspace
studies
recommended < 100
Prolific recommends keeping concurrent active studies under ~100 per workspace.
Bulk Bonus Payments study
participants
200 per request
A single bulk bonus payment can target up to 200 participants.

Policies

Retry-After
When present on a 429 response, honor the Retry-After header before retrying.
Backoff Strategy
Use exponential backoff starting at ~1s, doubling up to ~60s, with random jitter (+/- 20%), stopping after 5-6 attempts.
Prefer Hooks Over Polling
Subscribe to Hooks for study/submission events rather than polling the API to avoid unnecessary request volume.

Sources