> ## Documentation Index
> Fetch the complete documentation index at: https://docs.elestrals.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Abuse policy

> What gets a key flagged or revoked, in plain English.

The Elestrals API is shared infrastructure. We keep it fast and free-to-start by enforcing a small number of behavioral expectations on every key. This page is the plain-English version; the Developer Agreement is the binding one.

## What we watch for

Three signals feed our automated abuse flags. None of them auto-revoke; they trigger a manual review.

* **Quota saturation.** A key that consistently runs into the monthly quota during the first few days of the month, every month. Suggests scraping or a missing cache.
* **Traffic spikes.** 24-hour volume more than 5× the trailing 7-day average. Almost always indicates a broken retry loop or a recursive job.
* **Sustained 4xx rate.** ≥25% of requests in a 24-hour window returning client errors. Suggests a bug your client should fix, or probing for endpoints that don't exist.

These thresholds aren't trip wires. A one-day spike during a launch is fine. A scraper masquerading as a deck builder is not.

## What gets a key revoked

These are the behaviors that result in revocation, with no warning required:

* Republishing bulk Elestrals data — full card list, full set list, scraped image dumps — on a public website, mirror, or downloadable archive.
* Building a product whose core feature is a competing TCG database.
* Training machine-learning models on the corpus without prior written permission.
* Coordinating multiple keys to circumvent rate limits on a single workload.
* Distributing your API key publicly (committing to public repos, embedding in client-side JavaScript, posting in Discord).

The last one is special: a leaked key is a problem we'll work with you to solve, not a reason to lose access. [Rotate it immediately](/authentication#rotating-a-key) and let us know.

## What's fine

To rule out the obvious questions:

* **Heavy reads.** If you're a partner-tier deck-building tool serving 50,000 users, you should expect to use most of the partner quota. That's the system working.
* **Server-side caching.** Caching our responses on your own infrastructure is encouraged. Required, even, at the partner volumes.
* **Multiple keys for environments.** Mint a `dev`, `staging`, and `prod` key per developer. We expect this and the [usage dashboard](/monitor-your-usage) is built around it.
* **Community libraries.** Wrapping the API in an open-source SDK is fine. Embedding your bearer token in that SDK is not.

## What revocation looks like

If we revoke a key, you'll see it on your dashboard with a timestamp and a brief reason. Your account stays open; you can mint a new key after addressing the issue, with one exception: redistribution of bulk data and ML-training violations end the developer account.

For anything you're unsure about — a use case that lives near a line — write to support before you build it. Most "is this OK?" questions get a same-day answer, and ten minutes of email is cheaper than three months of work down a path we can't sign off on.