Removed http pull consumer limits

Author: maheshwarip

src/content/docs/queues/configuration/pull-consumers.mdx

@@ -96,7 +96,7 @@ curl "https://api.cloudflare.com/client/v4/accounts/${CF_ACCOUNT_ID}/queues/${QU
 --data '{ "visibility_timeout": 10000, "batch_size": 2 }'
 ```
 
-You may authenticate and run multiple concurrent pull-based consumers against a single queue, noting that all consumers will share the same [rate limit](/queues/platform/limits/) against the Cloudflare API.
+You may authenticate and run multiple concurrent pull-based consumers against a single queue.
 
 ### Create API tokens
 
@@ -248,7 +248,7 @@ Additionally:
 
 - You should provide every `lease_id` in the request to the `/ack` endpoint if you are processing those messages in your consumer. If you do not acknowledge a message, it will be marked for re-delivery (put back in the queue).
 - You can optionally mark messages to be retried: for example, if there is an error processing the message or you have upstream resource pressure. Explicitly marking a message for retry will place it back into the queue immediately, instead of waiting for a (potentially long) `visibility_timeout` to be reached.
-- You can make multiple calls to the `/ack` endpoint as you make progress through a batch of messages, but we recommend grouping acknowledgements to avoid hitting [API rate limits](/queues/platform/limits/).
+- You can make multiple calls to the `/ack` endpoint as you make progress through a batch of messages, but we recommend grouping acknowledgements to reduce the number of API calls required.
 
 Queues aims to be permissive when it comes to lease IDs: if a consumer acknowledges a message by its lease ID _after_ the visibility timeout is reached, Queues will still accept that acknowledgment. If the message was delivered to another consumer during the intervening period, it will also be able to acknowledge the message without an error.
 

src/content/docs/queues/platform/limits.mdx

@@ -18,15 +18,13 @@ import { Render, WranglerConfig } from "~/components"
 | Maximum messages per `sendBatch` call         									| 100 (or 256KB in total)                                       |
 | Maximum Batch wait time                       									| 60 seconds                                                    |
 | Per-queue message throughput    																| 5,000 messages per second <sup>2</sup>                        |
-| Message retention period <sup>3</sup>         									| 14 days                                                       |
+| Message retention period <sup>3</sup>         									| 4 days (default). [Configurable to 14 days](/queues/configuration/configure-queues#queue-configuration)                                                       |
 | Per-queue backlog size <sup>4</sup>           									| 25GB                                                          |
 | Concurrent consumer invocations               									| 250 <sup>push-based only</sup>                                |
 | Consumer duration (wall clock time) 														| 15 minutes <sup>5</sup>                                       |
 | [Consumer CPU time](/workers/platform/limits/#cpu-time)| 30 seconds (default). [Configurable to 5 minutes](/queues/platform/limits/#increasing-queue-consumer-worker-cpu-limits) 							|
 | `visibilityTimeout` (pull-based queues)       									| 12 hours                                                      |
 | `delaySeconds` (when sending or retrying)     									| 12 hours                                                      |
-| Requests to the Queues API (incl. pulls/acks) 									| [1200 requests / 5 mins](/fundamentals/api/reference/limits/) |
-
 
 
 <sup>1</sup> 1 KB is measured as 1000 bytes. Messages can include up to \~100 bytes of internal metadata that counts towards total message limits.