Quick question about… hitting 429 Too Many Requests on the /api/v2/conversations/messaging/messages endpoint while running a concurrent load test from Singapore. Setup involves JMeter 5.6.2 with 100 virtual users sending text messages to a single bot endpoint via the Platform API. The test plan uses a CSV Data Set Config for unique participant IDs and a constant throughput timer set to 10 samples/second per thread group. Initially, requests succeed with 201 Created responses, but after roughly 50 seconds, the error rate spikes to 40% with 429 status codes and Retry-After headers suggesting a 10-second wait. The x-gc-request-id headers are unique, and OAuth tokens are refreshed every 50 minutes to avoid expiration issues. Is this a hard limit for the messaging API, or is there a specific header or pagination strategy that helps distribute the load better? Also, wondering if the WebSocket connection limit for the /api/v2/analytics/events/streams endpoint is being hit simultaneously, causing cascading failures. Any insights on the actual rate limit thresholds for bulk message ingestion would be appreciated.