Does datastream also uses the Streaming API guadrail of 1500 requests/second | Community
Skip to main content
arpan-garg
Community Advisor
arpan-gargCommunity Advisor
Community Advisor
March 25, 2026
Question

Does datastream also uses the Streaming API guadrail of 1500 requests/second

  • March 25, 2026
  • 3 replies
  • 36 views

Hello, I have data coming from the website via websdk and it is possible that we end up receiving more than 1500 request/second. Our organization has a streaming API limit of 1500requests/second, does data sent via websdk use this?

 

Thanks,

Arpan

    3 replies

    Amruthesh_AG
    Community Advisor
    Amruthesh_AGCommunity Advisor
    Community Advisor
    March 25, 2026

    Web SDK data sent via Datastream does not use or count toward the Streaming API guardrail of 1500 requests/second. These are two different ingestion paths.

    Web SDK requests go through the Adobe Experience Platform Edge Network, where Datastream acts as a routing layer to services like Analytics and Target. The Streaming API limit applies only to direct server-side ingestion via the Streaming Ingestion APIs, not to Web SDK traffic.

    That said, if your website generates very high traffic, it’s still important to optimize event firing (avoid duplicate calls, unnecessary events, or loops) because the Edge Network can apply its own rate limiting in extreme cases.

    So in short:

    Web SDK + Datastream →  Not counted in Streaming API limit

    Streaming API →  Subject to 1500 req/sec limit


    Hope this helps clarify!

    arpan-garg
    Community Advisor
    arpan-gargCommunity AdvisorAuthor
    Community Advisor
    March 25, 2026

    Hey ​@Amruthesh_AG , thanks for the reply. I actually thought the same thing initially, but we just got burned by this in our sandbox.

    We ran a load test sending roughly 100k requests/sec through the Web SDK and immediately got hit with a 'Streaming Capacity Breached' alert in the AEP dashboard. It turns out that while the Edge Network itself is built for massive scale, the second you toggle the 'Adobe Experience Platform' service in your Datastream, that data is funneled into the same 1,500 req/sec streaming pipe as the server-side API.

    I ended up opening a support ticket to be 100% sure, and Adobe confirmed that the 1,500 limit is an aggregate for the entire sandbox. Basically, it doesn’t matter if the data starts in a browser or on a server—if it’s destined for the AEP Profile, it’s all hitting that same bottleneck.

    Thanks,

    Arpan

    SG14_97
    SG14_97
    Level 3
    March 26, 2026

    Hi ​@arpan-garg,

    From what we have experienced previously the 1500 req/sec applies to all the below - 

    • Web SDK / Edge Network events hitting profile-enabled datasets
    • Streaming API calls
    • Streaming source connectors (e.g., Kafka, Kinesis, Event Hubs) going into profile

    While batch ingestion guardrails (even for events) are separated out from the limit. Also we got some confirmation that the internal streaming data generated by Adobe doesn’t count towards this limit.

     

    Regards,
    Sayantan 

    arpan-garg
    Community Advisor
    arpan-gargCommunity AdvisorAuthor
    Community Advisor
    March 26, 2026

    Hi ​@SG14_97  - This is exactly the same we experienced, Data sent via sdks is considered in this limit if the data is being sent to UPS. We also got the confirmation that the limit on wesdk and mobilesdk  is either 4000 rps or 6000 rps depending on if we are using interact or collect endpoint. Adobe will continue to take more requests even if we exceed this limit, however the system can throw 429 error so any request beyond this guadrail should be retried by the client side logic.

      A
      Abie
      Level 4
      March 26, 2026

      Hi ​@arpan-garg ,

       

      Most of the details are already mentioned but one, this limit is not just for one sandbox but for all the sandboxes in the organization. If you have multiple sandboxes, then the Production instance gets even less share of the total requests. May be something you can try to finetune.

       

      To add, we also bumped into this problem and we ended up writing a wrapper on top of these APIs, to-

      1. Handle throttling
      2. Standardize API requests.
      3. Adobe specific payload transformation.

      For websdk I can imagine, it is a challenge because it is directly between the client (browser/app) and the Edge network and then to AEP. May be you can try to explore configuration options in Data Streaming.

       

      For one of the use-cases, we actually forwarded unwanted events to a dataset that was not enabled for profiling. The 1500 rps limit does not apply to that. 

       

      I hope it helps.

       

      Thanks!

      Terms & ConditionsAccessibility statement

      Loading footer...