Consume Cloudflare Queue messages over HTTP using pull-based consumers (non-Workers clients), including enabling pull mode, pulling batches, and acknowledging/retrying messages.

Documented steps

1. Choose pull over push when you need to consume from existing infrastructure outside Workers or need fine-grained control over consumption rate. See https://developers.cloudflare.com/queues/configuration/pull-consumers/
2. Enable HTTP pull on an existing queue via Wrangler: `npx wrangler queues consumer http add $QUEUE-NAME`. If the queue already has a push-based (Worker) consumer, remove it first with `wrangler queues consumer worker remove $QUEUE-NAME $SCRIPT_NAME`, since a queue can't have both types at once (and you must also delete any leftover `[[queues.consumer]]` block from the Wrangler config or subsequent deploys will fail).
3. Create an API token: dashboard > My Profile > API Tokens > Create Token > Create Custom Token > under Permissions choose Account > Queues > Edit (read+write) > scope to account(s) > Continue to summary > Create Token. This grants both the queues#read and queues#write (com.cloudflare.api.account.queues_read / queues_write) permissions required — write is needed because acknowledging messages mutates queue state.
4. Pull a batch of messages: `POST https://api.cloudflare.com/client/v4/accounts/${CF_ACCOUNT_ID}/queues/${QUEUE_ID}/messages/pull` with header `Authorization: Bearer ${QUEUES_TOKEN}` and JSON body { "visibility_timeout_ms": 10000, "batch_size": 2 } (or {} to use defaults).
5. Read the response's `result.messages` array; each message has `body` (base64-encoded for json/bytes content types, plain UTF-8 for text), `id`, `timestamp_ms`, `attempts`, and a `lease_id` used to ack/retry it. `result.message_backlog_count` reports the remaining queue depth.
6. Process each message, then acknowledge or retry it via `POST .../queues/${QUEUE_ID}/messages/ack` with body { "acks": [{ "lease_id": "..." }, ...], "retries": [{ "lease_id": "..." }] }; optionally add "delay_seconds": <n> to a retry entry to delay its redelivery.
7. Always submit every lease_id you processed to /ack — unacknowledged messages are simply put back in the queue once `visibility_timeout` expires (not explicitly failed), so silent drops just cause redelivery after the timeout rather than data loss.
8. For concurrent throughput, run multiple HTTP pull clients against the same queue simultaneously — each pull call gets a distinct batch and its own lease; messages aren't tied to a specific consumer identity.
9. Ensure producers only publish messages with `text`, `bytes`, or `json` content type (`json` is the default) to any queue with a pull consumer attached — the pull API cannot decode the Workers-runtime-specific `v8` content type.