Rate limiting at destinations

Previously I had seen the following question regarding Segment's handling of rate limiting at destinations.

That question mentions that when a destination returns a 429 status code it is retried 5 times for 30 minutes but only for requests coming from a server application.

However, when this occurs, under the "Event Delivery" tab of a destination a different message is shown, and in the sample payloads, I can see requests coming from mobile devices.



Segment retries these requests 9 times over a four hour period, with exponential backoff. You should not see any data loss due to rate-limiting, but may see a number of errors.

Has this been changed? Do frontend requests also get retried now?

3replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Hi Danny, thanks for reaching out!
    All mobile libraries handle retries by periodically attempting to flush their internal queue of events to Segment. If the flush is unsuccessful, the library will wait until the next regularly-scheduled flush time to try again. The background queue of requests to Segment is bounded in size so if events are being queued faster than we can successfully flush them to Segment, some events may be dropped. 
    More information on retries you can find in our docs .
    I hope that helps! Cheers

  • Hey Yannick, thanks for the reply, the link to the docs helps!

    Though your answer is related to retries between mobile apps and Segment, I'm asking about retries between Segment and the destinations for requests that originally comes from mobile applications.

    But I assume those are also retried since in the documentation link you sent, the "Retries between Segment and Destinations" section doesn't distinguish the frontend SDKs from the server ones. Is my assumption correct in that case?

  • Hi Danny! Yes, your assumption is correct! :)