IP blocked for research group cloud server (IP: 47.85.54.98)

Hi MP team,

Our group’s cloud server IP (**47.85.54.98**, Alibaba Cloud US, AS45102) has been blocked with a 403 error citing “inefficient or abusive traffic.” We work on battery materials, heterogeneous electrocatalysis, and water electrolysis (OER/HER), and use the MP API for high-throughput screening pipelines — with multiple group members sharing one cloud server.

The full error message we receive:

```

“Your IP address or ASN has been (temporarily) blocked from accessing all MP services due to inefficient or abusive traffic. Please make yourself familiar with our terms, make sure to run the latest version of the mp-api client ( mp-api · PyPI ), read our documentation…”

```

Following your official large-download guidelines, we have since:

- Upgraded to the latest `mp-api` version

- Always batch list queries instead of per-material-ID loops

- Restricted returned fields with `fields=[…]`

- Implemented local caching to avoid redundant requests

- Added rate limiting to stay within 25 req/s

The block appears to have been applied before we had the chance to make any corrections, and it persists despite our fixes.

Is there a formal process to request whitelisting for shared research group infrastructure? Our automated pipeline has no fallback at the moment, so any guidance would be greatly appreciated.

Thank you.

Yirui

Hey @yirui_lu, I’ll pass this along to @tschaume to review the cloudflare block

Besides that, it sounds like multiple group members are sharing an API key? It’s really important that each individual user has their own API key, since this allows us to report accurate usage metrics to our government funding agencies

Additionally, it sounds like you would benefit strongly from caching the data locally rather than making repeated requests to the database. You can always cache our data directly from the client, or use the mirror of it on AWS S3 OpenData

Hi @Aaron_Kaplan thanks for the quick response!

We share only the cloud server (and its outbound IP), while each group member uses their own individual API key.

Thank you so much for your advice on local caching — we’ve already downloaded the S3 OpenData mirror and it’s working great for our screening workflows.

We’d still appreciate the IP unblock when possible, as some data isn’t available locally and requires direct API access. @tschaume Thank you in advance for your help!