A generic acceptable use policy assumes a person is on the other end of the connection, clicking through a dashboard and occasionally doing something they shouldn’t. A developer API platform has a different problem: the party agreeing to the policy is a developer, but the traffic hitting the platform is code, running unattended, capable of making more requests in a minute than a person could make in a week. Our general guide to writing an acceptable use policy covers the baseline every SaaS platform needs: a prohibited-use list and a graduated enforcement structure. This one covers what a developer-facing API adds on top of that baseline, because scraping, rate-limit circumvention, and API-key handling are not edge cases for this kind of platform. They are the main event.
Why a Generic Prohibited-Use List Falls Short
A prohibited-use list written for a web app, no spam, no malware, no unauthorized account access, is not wrong for an API platform, it is just incomplete. It has nothing to say about a customer’s script that fires a request every 200 milliseconds around the clock, a competitor’s crawler pulling structured data through an authenticated endpoint instead of scraping the public site, or a customer who signs up for one seat and then hands the API key to a dozen internal tools with no idea how much combined load they are putting on the platform.
Those are the abuse patterns specific to programmatic access, and a policy that only lists content violations and account-sharing has no language to point to when one of them shows up. The list below is what a developer platform’s acceptable use policy needs in addition to the standard categories, not instead of them.
Prohibited Automated Access and Scraping
The core distinction an API-platform AUP has to draw is between sanctioned automated use, which is the entire point of offering an API, and automated use that circumvents the terms under which access was granted. Both involve a script making requests. Only one of them is what the customer signed up for.
Sanctioned API use vs. prohibited scraping
| Sanctioned integration | Prohibited scraping | |
|---|---|---|
| Authenticates with an issued API key | ||
| Requests documented, published endpoints | ||
| Stays within the account's rate limit | ||
| Bypasses the API to scrape undocumented endpoints | ||
| Uses multiple keys to evade a single account's limit |
The clause needs to name both halves of this explicitly: a prohibition on scraping or crawling any part of the platform outside the documented API surface, and a separate prohibition on using the documented API itself in a way that circumvents its rate limits, whether through request patterns designed to evade throttling, distributing calls across multiple accounts or keys to stay under a per-account cap, or reverse engineering the platform’s internal endpoints to pull data the public API does not expose. Naming the second category matters because it is easy for a customer to argue, in good faith or not, that using the official API however they like cannot be a violation of anything. The policy has to say plainly that it can be.
Rate Limits Belong in the Enforcement Clause, Not Just the Technical Docs
A rate limit is usually treated as a purely technical setting, a 429 response and a retry-after header, with no policy language attached to it at all. That gap is a mistake for an AUP specifically, because the policy is what gives the platform standing to do something about a customer whose behavior around the limit is itself the problem, apart from any single request being individually fine.
The clause should state that repeatedly or deliberately exceeding the published rate limit for the account’s plan is a violation of the policy, distinct from simply hitting the limit occasionally under normal load. It should also say what the platform can do in response, on a scale that matches the severity, rather than jumping straight to suspension for an account that is simply growing faster than its current plan.
The distinction between “hitting the limit” and “evading the limit” is the one a first draft of this clause most often skips, and it is the distinction that actually matters for enforcement, because a customer whose traffic naturally grew past their plan needs a path to a bigger plan, not a suspension notice. Our guide to writing a SaaS SLA covers the uptime side of this same boundary: hitting a rate limit is an acceptable-use and account-management matter, not an uptime miss under any service level commitment the account is also subject to, and the two documents should agree on that rather than leaving a customer to guess which one governs a throttled request.
API Key Handling as a Prohibited-Use Category
An API key is the credential the entire policy hangs on, so the AUP needs its own clause about what a customer cannot do with one, separate from the rate-limit and scraping language above. State plainly that a customer may not share a single issued key across more accounts, teams, or products than the plan permits, may not sell, sublicense, or otherwise provide a third party with access to the platform under their own key, and must rotate a key immediately if it is exposed in a public repository, a client-side application, or any other place it should not have been.
That last point is worth stating as an affirmative obligation rather than leaving it implied, because a leaked key is the single most common reason a platform needs to revoke access on an emergency basis, and the policy reads more defensibly when it can point to a specific clause the customer agreed to about their own responsibility for key hygiene, not just a general “keep your credentials safe” line buried in the account-security section.
- "Users may not misuse the API"
- "Excessive use may result in account action"
- No mention of scraping, key sharing, or evasion patterns
- "No scraping outside documented, authenticated endpoints"
- "No distributing requests across multiple keys to evade a rate limit"
- "Leaked keys must be rotated immediately; unrotated leaked keys may be revoked without notice"
Revocation itself, the actual mechanics of pulling a key and what notice period applies to a security event versus a billing or policy issue, is contract language that belongs in the platform’s terms and conditions rather than the AUP. Our guide to terms and conditions for a SaaS API platform covers that revocation clause in full, including the split between immediate, no-notice revocation for a compromised key and a cure-window process for a policy violation. The two documents work together: the AUP defines what counts as a violation, the terms define what happens to the key once one occurs.
Downstream Use and Output Restrictions
The last category a developer-platform AUP needs, and one a policy written for a person-facing product has no reason to include, covers what a customer is allowed to do with what the API returns. If the platform’s responses include data, content, or model output of any real value, the policy should state whether that output can be resold as a standalone dataset, used to train a competing product, or redistributed to the customer’s own end users without attribution or limits the platform intends to enforce.
This does not need to be an exhaustive licensing clause, that level of detail belongs in the terms and conditions or a separate data license, but the AUP should at minimum flag it as a category the platform reserves the right to enforce against, alongside the access and rate-limit provisions. A prohibited-use list that only covers how a customer connects to the API and says nothing about what they do with what comes back is missing the category most likely to actually matter commercially.
Putting the Developer-Specific Clauses Together
A developer-platform AUP still needs everything a standard SaaS acceptable use policy needs: the general prohibited-content categories, the account-security provisions, and a graduated enforcement structure with defined response times. What sits on top of that baseline for this kind of platform is scraping and evasion language specific to automated access, a rate-limit clause that treats sustained or deliberate overage as its own violation category, an API-key clause covering sharing, resale, and mandatory rotation after exposure, and a statement on what customers can do with the API’s output. Skip any of those four and the policy still reads like it was written for someone browsing a web app, not a program calling an endpoint thousands of times an hour. Our acceptable use policy generator includes these developer-platform provisions as options when a product is described as an API, so the scraping, rate-limit, and key-handling language is built into the document from the start rather than drafted separately after the fact.
