LINE error 429: Too Many Requests (concurrent audience operations)
Last verified against LINE Developers - Messaging API reference (error responses)
<detail varies>What error 429 means
This is the third documented meaning of 429 on the Messaging API: not request rate, not monthly quota, but parallelism. The reference sets "a limit on the number of concurrent endpoint operations per audience ID (audienceGroupId), for creating an audience for uploading user IDs and adding user IDs to an audience" - the four upload-audience endpoints (create by JSON, create by file, add by JSON, add by file) share a combined maximum of 10 concurrent operations. Cross it and: "Requests that exceed the limit on the number of concurrent operations will return an error with status code 429 Too Many Requests. If you've received an error, wait a while before making a request again."
Concurrency here is measured by job state, not by open HTTP connections. Audience uploads are processed asynchronously; the docs tell you to count jobs via the get-audience-data endpoint: "if the status of a job (jobs[].jobStatus property) is waiting to run (QUEUED) or running (WORKING), it will be counted as an operation." So a burst of add-user-IDs calls can trip the limit even if each HTTP request returned quickly - the queued jobs are still "operations" until they finish.
Distinguish this from the sibling 429s by context: it occurs on audience-management endpoints during bulk segment builds, while the rate-limit 429 is about request frequency anywhere and the monthly-limit 429 carries its own message string. Audience endpoints additionally have a 60-requests-per-minute rate limit, so aggressive uploaders can hit either ceiling.
What it looks like
HTTP/1.1 429 Too Many Requests
// Returned when more than 10 audience upload/update operations
// are QUEUED or WORKING at the same time. Wait, then retry.Why it happens
- Parallel workers splitting one big user-ID list into many simultaneous add-to-audience calls against the same audienceGroupId.
- Retry logic resubmitting uploads while earlier jobs are still QUEUED or WORKING.
- Multiple pipelines (e.g. CRM sync plus campaign tool) writing to audiences at the same time.
- Treating the async 202 acceptance as completion and immediately issuing the next chunk.
How to fix LINE error 429
- 1Serialize audience mutations: run one upload job at a time per audience, or cap your worker pool well under 10.
- 2Poll GET /v2/bot/audienceGroup/{audienceGroupId} and proceed only when no jobs are QUEUED or WORKING.
- 3On 429, back off and re-check job status before retrying - the operation slots free up as jobs complete.
- 4For very large lists, prefer one create-by-file upload (up to 1,500,000 user IDs) over thousands of JSON chunks.
How to stop it recurring
Model audience building as a queue with completion tracking, not fire-and-forget: submit, poll jobs[].jobStatus, then submit the next chunk. Prefer the file-based endpoints for bulk loads so one job replaces many, and keep the 60-requests-per-minute endpoint budget in mind for the surrounding calls. See audience limits for the full set of caps.
Official reference: LINE Developers - Messaging API reference (error responses). See all LINE error codes or the LINE limits and quotas.
Related codes
Error 429 - quick answers
What does LINE error 429 mean?
This is the third documented meaning of 429 on the Messaging API: not request rate, not monthly quota, but parallelism.
How do I fix LINE error 429?
1. Serialize audience mutations: run one upload job at a time per audience, or cap your worker pool well under 10. 2. Poll GET /v2/bot/audienceGroup/{audienceGroupId} and proceed only when no jobs are QUEUED or WORKING. 3. On 429, back off and re-check job status before retrying - the operation slots free up as jobs complete. 4. For very large lists, prefer one create-by-file upload (up to 1,500,000 user IDs) over thousands of JSON chunks.
Can I retry after error 429?
Yes - this is a retryable condition. Back off (start around one second and double on each attempt, with jitter) and watch for a retry-after hint from the platform before resending.
Stop debugging LINE by hand
Connect the channel through Conferbot: tokens, webhooks and retries are handled, failures show as readable status.