[ensembl-dev] Noticing very slow requests on `rest.ensemble.org`

[Stefano Giorgetti]

Dear Kat,

Thank you for reaching out to us and for the helpful diagnostics.

You are correct in observing a change in Ensembl REST API behaviour.
On 16th February we temporarily introduced additional traffic controls 
as part of a security investigation.
This included more aggressive throttling of certain traffic patterns and 
user agents while we assessed and mitigated the issue.

Those measures have now been relaxed and normal service parameters have 
been restored.
However, we are still seeing elevated levels of automated traffic, and 
some requests — particularly those matching common programmatic user 
agents — may intermittently experience increased latency while our 
safeguards continue to operate.

Your reported usage pattern (a few requests per minute) is entirely 
reasonable and should not require any changes on your side.
That said, as a general best practice, we recommend:

  *

    Including a descriptive User-Agent string that identifies your
    application (e.g. |YourAppName/1.0 (contact at email)| rather than the
    default |python-requests/x.y.z|).

  *

    Implementing exponential back off and retry handling for occasional
    transient slowdowns.

  *

    Avoiding burst patterns where possible.

We are continuing to monitor traffic closely and fine-tune the controls 
to minimise impact on legitimate users.
Please let us know if you continue to experience significant delays over 
the coming days, and we will be happy to investigate further.

Thank you for your patience and for using the Ensembl REST API.

Kind regards,

SG

-- 
------------

Stefano Giorgetti - Ensembl Platform Lead
The European Bioinformatics Institute (EMBL-EBI)
Wellcome Genome Campus
Hinxton, Cambridge
CB10 1SD, United Kingdom

https://www.ensembl.org/


On 19/02/2026 6:33 pm, Kat Salameh wrote:
> Hello,
>
> We use the ensembl REST API to look up genome data in our application, 
> typically at the rate of a few requests per minute at most. We've 
> noticed recently that requests to `rest.ensembl.org 
> <http://rest.ensembl.org/>` have been taking an exceptionally long 
> time. Specifically, since about 21:00 UTC on February 16, we've been 
> seeing over half of requests to any `rest.ensembl.org 
> <http://rest.ensembl.org/>` endpoint take more than 30 seconds. There 
> aren't any changes to the statuses or other data returned that I can 
> see, just that requests have suddenly begun to take an extremely long 
> time.
>
> I tried testing on my laptop with `curl` to see if I could reproduce 
> the issue, and it did happen when I tried to use the same user agent 
> string as our script/application.
> For example:
> -The command `curl 
> https://rest.ensembl.org/info/assembly/homo_sapiens\ 
> <https://rest.ensembl.org/info/assembly/homo_sapiens%5C> -H 
> "Content-Type: application/json"` returns a result from the server in 
> less than a second from my laptop, which is what I would expect.
> - Using the same user agent as my laptop's Chrome browser has the same 
> result.
> - However, if I add `-A "python-requests/2.32.4"` to that curl 
> command, mimicking the python requests user agent we use for 
> programmatic access in our application, the same request now takes 
> between 45-120 seconds or more.
>
> Did anything change about the configuration of `rest.ensembl.org 
> <http://rest.ensembl.org/>` that might be causing requests to be 
> delayed by 10s of seconds? Should we change how we're requesting data 
> from `rest.ensembl.org <http://rest.ensembl.org/>` to address this 
> issue? Any guidance would be appreciated. Thank you!
>
> Best,
> Kat Salameh
> Software Engineer at Benchling
>
> _______________________________________________
> Dev mailing listDev at ensembl.org
> Posting guidelines and subscribe/unsubscribe info:https://lists.ensembl.org/mailman/listinfo/dev_ensembl.org
> Ensembl Blog:http://www.ensembl.info/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ensembl.org/pipermail/dev_ensembl.org/attachments/20260219/8da3481b/attachment-0001.html>