Short answer: if you expose an API, you need an API license agreement for two reasons. Your developer use case will change, and you have to set expectations so developers do not build businesses on access you never promised to keep. Everything else follows from those two facts. Copyright will not reliably protect your API, the Computer Fraud and Abuse Act will not either, and the only instrument that reliably defines what a developer may do with your endpoints is the contract you put in front of them before you hand over a key. The clause that does the most work is the one reserving your right to change or discontinue the program.
By Jeremy Aber, software and SaaS attorney. Vendor side only.
I put off writing about API license agreements for years because I could not find a good real world example. Then Twitter handed me one, and then kept handing me one, roughly every three years, for the next decade. Here are the two reasons software and SaaS companies with an API need an agreement instead of going naked, plus what I have learned about drafting them since.
For background: in 2012 Twitter changed its API licensing terms to further restrict what its API developers could build (over 750,000 registered apps at the time). Twitter wanted developers building “tools,” not businesses or applications that competed with Twitter itself.
1. Your API Developer Use Case Will Change.
Things move fast in software and API licensing. You open your API, discover you opened it too far, and then want to pull it back. Twitter hit exactly that: developers were using the API to compete with Twitter or to duplicate its interface, confusing the market about what Twitter even was.
Most API license agreements are one sided, and reasonably so. You are giving something away, usually for free, and it is your technology. So you can change the terms. But if you have no agreement and then change your API program, your developers get upset, and if they lose money they will send you complaints and sometimes a lawsuit. The agreement is what limits your exposure when the model shifts.
The thing worth noticing is that Twitter did not change its API once. It changed it repeatedly. The 2012 restriction was followed years later by the deprecation of legacy endpoints, and then by a move to paid access tiers that ended the third party client market outright. Long running apps like Tweetbot and Twitterrific, which had been built on the old terms, simply stopped working. Reddit ran the same play on its own timeline, and the third party client Apollo shut down rather than pay the new pricing.
Nobody drafting an API program in 2012 predicted the 2023 version of that program. That is the entire point. You are not drafting for the model you have now. You are drafting for the model you will have after two pivots and a monetization push, and the only way to preserve that freedom is to reserve it in writing on day one.
2. Communicate the Right Expectations to Your API Developers.
Like any agreement, an API license agreement communicates your model and sets expectations about what developers can and cannot do. Developers actually want to know where the boundaries are. Ambiguity is not generosity, it is future litigation.
If Twitter had not had an agreement carrying (a) a limitation of liability, (b) a disclaimer of warranties, and (c) express language reserving the right to change the terms, it would have been sued over that change. Developers would have argued they relied on unrestricted access, built businesses on it, and could not be cut off without compensation. With those three clauses in place, that argument mostly evaporates.
Do Not Rely on Copyright Alone.
Some vendors assume the law protects their API even with no agreement. It is not that simple. In Google LLC v. Oracle America, the Supreme Court held in 2021 that Google’s reuse of Java API declaring code was a fair use, and it pointedly declined to decide whether that code is copyrightable at all. So the highest court in the country looked directly at the question every API vendor cares about and chose not to answer it.
The doctrinal reason it is a hard question sits in 17 U.S.C. section 102(b), which excludes any “method of operation” from copyright protection. An API is arguably the purest method of operation in software. Reasonable people disagree about where the line falls, which is exactly why you do not want your business model resting on it. Your license terms are doing the real work of defining what developers may do, and the reasoning in the case is worth reading if you build on other people’s interfaces too, which I covered in more depth in the Oracle versus Google decision.
The CFAA Will Not Save You Either.
The other thing vendors reach for is the Computer Fraud and Abuse Act (18 U.S.C. section 1030), on the theory that a developer who ignores your rules is accessing your system without authorization. That theory got a lot narrower.
In Van Buren v. United States (2021), the Supreme Court read “exceeds authorized access” as a gates up or gates down question. If you have permission to reach the data at all, using it for a purpose your terms prohibit is not a federal computer crime. Breaking your terms of use is a contract problem, not a CFAA problem.
The Ninth Circuit had already pointed the same direction in hiQ Labs v. LinkedIn, where the CFAA claim could not reach the scraping of publicly available profile data. What eventually worked for LinkedIn was its user agreement. The statute failed and the contract carried it.
Put those two cases side by side and the vendor lesson is blunt. Federal computer crime law protects the lock on the door. Your contract is what defines the rooms a developer is allowed to walk into once you hand over the key. If the contract does not say it, effectively nothing does.
What an API License Agreement Should Contain.
At a minimum, a vendor side API license agreement should cover:
- A scoped grant. What the developer may and may not build, plus any field of use limits. This is where you say “no products that substantially replicate our user interface” if that is the concern.
- Rate limits and acceptable use by reference. Put the numbers in a policy you can update, and reference the policy from the agreement. Never hard code a rate limit into a contract you would need an amendment to change.
- Right to change, suspend, or discontinue. Clear language covering the terms, the pricing, the endpoints, and the program itself, with a stated notice mechanism.
- Versioning and deprecation. How long a version is supported and how sunset gets announced. Silence here is what generates the angry blog posts.
- IP and data. Who owns what, whether the developer may store or cache your data, and how end user data may be used.
- Limitation of liability and warranty disclaimer. Most important on a free program, for the reason in the next section.
- Assent mechanics. Click to accept at key issuance, not a link buried in a footer.
- Suspension for cause, and immediate suspension for abuse. Two different remedies with two different triggers.
The instinct behind all of it is the same one behind the restrictions you put in any software license, and the clause set overlaps heavily with what belongs in your main SaaS agreement.
Free Tier, Paid Tier, and Where the Liability Sits.
Vendors tend to worry less about the free tier. That is backwards. A free tier attracts volume, volume attracts unpredictable use, and a free user with no contract cap can still cost you a defense budget. Here is how the two tiers actually differ on risk:
| Issue | Free tier | Paid tier |
|---|---|---|
| Who accepts the terms | Whoever clicks through at signup | A negotiated signature or an order form |
| Realistic liability cap | Zero, or a nominal fixed dollar figure | Fees paid, usually over 12 months |
| Uptime commitment | None, and say so expressly | An SLA with credits as the sole remedy |
| Right to cut off access | Immediate, for any reason | Notice and a cure period, with abuse carved out |
| Where the real risk is | Reliance claims from businesses built on free access | Scope creep beyond the licensed use case |
The cap is the piece vendors get wrong most often. A free program with no cap is an uncapped obligation with no revenue behind it, which is the worst trade in the document. I walk through the three cap structures I use in SaaS agreement liability models, and the same logic applies here with the numbers set lower.
Deprecation Is a Contract Term, Not an Engineering Decision.
Engineering decides when a version should die. The contract decides whether you are allowed to kill it. Those are different questions and vendors routinely discover the difference at the worst moment.
Write down the support window for a released version, the notice period before sunset, and the channel notice arrives through. Then hold to it, because a published deprecation policy you actually follow is worth more commercially than a vague reservation of rights you invoke without warning. Developers will forgive a sunset they saw coming. They will not forgive a surprise, and the ones who do not forgive you write the posts that make your API a cautionary tale.
Who Owns the Data the Developer Collects.
Every API program eventually raises a data question, and it is usually three questions wearing one coat.
First, your data flowing out: may the developer store it, cache it, redistribute it, or use it to train a model? Say so explicitly, because in 2026 the training question comes up in almost every negotiation and silence gets read generously by the other side. Second, end user data the developer collects through your integration: who is the controller, and does your program create a processor relationship that needs a data processing agreement behind it? Third, usage telemetry you collect about the developer: disclose it, and make sure your privacy documentation matches what you actually do.
If your API touches personal data, the answers here are not just commercial. They drive your privacy posture, and it is worth having a data privacy lawyer look at the flow before the program launches rather than after a customer asks about it in a security review.
How to Cut Off a Developer Without Getting Sued.
Sooner or later you will need to shut someone down. The pattern that holds up is boring and procedural. Document the breach against a specific provision. Send written notice through the channel the agreement names. Give the cure period the agreement promises, unless the conduct falls inside your abuse carve out. Then revoke access, and revoke the credential rather than relying on a request to stop.
That last step matters more than people expect. The cases that went well for platforms turned on a clear, documented revocation of permission, and the ones that went badly turned on a platform that grumbled about conduct for months while continuing to serve traffic. Revocation is an act, not an opinion. Do it cleanly, in writing, once.
Frequently Asked Questions.
Can I change my API terms after developers have built on them? Yes, if your agreement reserves the right to change or discontinue the program with notice. Without that language, developers may claim they relied on the old terms, and that claim gets stronger the longer the old terms sat unchanged.
Is my API protected by copyright automatically? Not reliably. After Google v. Oracle, API reuse can be a fair use, and copyrightability of the declaring code was left open. Section 102(b) of the Copyright Act excludes methods of operation, which is the source of the uncertainty. Your contract, not copyright, is what protects you.
Can I use the Computer Fraud and Abuse Act against a developer who breaks my terms? Usually no. Van Buren limited “exceeds authorized access” to a gates up or gates down test, so misusing data you were allowed to reach is a contract claim rather than a federal crime.
What is the single most important clause? The right to change or discontinue the program, paired with a strong limitation of liability and warranty disclaimer.
Do I need a separate agreement, or can the API terms live inside my main SaaS agreement? Either works, but keep the API terms in a separate document or exhibit you can version independently. Your API program will change on a faster clock than your subscription agreement.
Does a free API program still need a signed agreement? It needs assent, not a signature. Click to accept at key issuance is the practical standard, and it is what makes your cap and disclaimer enforceable against a free user.
For the broader framework on choosing between subscription and license structures, see SaaS Agreement vs. Software EULA: Which Template Do You Need? If you need an API program papered, a software attorney who works only the vendor side can scope the grant and the change of terms language correctly.
Resources:
What Does Your SaaS Agreement Liability Model Look Like?
Indemnities: 4 Things You Should Know
SaaS Agreement Template: Key Clauses Checklist
Last updated: July 25, 2026.
Disclaimer:
This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.
Discover more from Aber Law Firm
Subscribe to get the latest posts sent to your email.