Key Takeaways
- •An AI API terms of service is the binding contract between the company offering a model over an API and the developers calling it. It sets output ownership, training-data rights, acceptable use, rate limits, indemnity, and the liability cap.
- •Default to user ownership of outputs with a non-exclusive license back to you. That is where OpenAI, Anthropic, and Google all landed by 2024, and a clause that grabs outputs for the provider reads as predatory.
- •If you ever process EU personal data through the API, a separate Data Processing Agreement under GDPR Article 28 is mandatory. The terms cannot absorb it, and the EDPB's 2023 guidance says vague 'service improvement' is not a lawful basis to train on customer prompts.
- •Silence on training rights invites a CCPA and FTC complaint, so spell them out in plain language. Anthropic committed in writing not to train on inputs or outputs, while OpenAI defaults to collection with an enterprise opt-out.
- •Your acceptable use policy carries real weight under the Computer Fraud and Abuse Act and FTC Act Section 5. Ban illegal use, IP infringement, non-consensual intimate imagery, CSAM, and malware, and define how you enforce throttling and termination.
- •Cap liability at fees paid in the trailing twelve months and exclude consequential damages, but add an 'except where prohibited by applicable law' rider. GDPR Article 82 liability and several state statutory-damages schemes cannot be contracted away.
- •This page is educational and is not legal advice. AI law is moving fast, and you should confirm current statutes, the status of pending copyright litigation, and your own data flows with counsel before publishing terms.
Reviewed for accuracy by the document.com legal team. Educational information, not legal advice.
What Is AI API Terms of Service?
AI API terms of service are the binding contract a company sets when it lets outside developers send requests to its machine-learning model through an application programming interface. The document spells out the terms that determine whether the relationship is safe to enter: who owns what the model generates, whether the provider may keep customer prompts and use them to train future versions, what the developer is forbidden from building, how rate limits and outages are handled, and who absorbs the loss when an output infringes a copyright or causes harm.
These terms sit at the intersection of three bodies of law that did not contemplate generative models: contract law for the bargain itself, data-protection law for the prompts and outputs that flow through the pipe, and intellectual-property law for the training data on the back end and the generations on the front end. A clause that is perfectly enforceable as a matter of contract can still be void under the General Data Protection Regulation or the California Consumer Privacy Act, so the drafting has to clear all three at once.
Practically, an AI API terms of service is rarely a single file. It anchors a small constellation: the core terms, an acceptable use policy, a privacy policy, and, for any provider touching EU data, a Data Processing Agreement. Enterprise customers will also want a service-level agreement and a sub-processor list. The core terms tie these together and tell the developer which document controls when they conflict.
Why This Matters Now
The Federal Trade Commission spent 2023 and 2024 warning AI companies that overstated capability claims and quiet data practices are deceptive acts under Section 5 of the FTC Act, and it has opened inquiries into model providers over exactly the kind of safety and privacy representations that live in terms of service. A set of terms that promises more than the model delivers is now an enforcement target.
The copyright fights that will define this market are in active litigation. Authors Guild v. OpenAI is pending in the Southern District of New York, and Getty Images v. Stability AI is moving through the Northern District of California. Until those produce appellate law on whether training on copyrighted works is fair use, every set of terms has to allocate that risk by contract, because the courts have not allocated it by precedent.
The European Data Protection Board's December 2023 guidance signaled that 'service improvement' is unlikely to be a sufficient lawful basis for training a model on personal data without a stronger footing, often consent. Providers that buried a training right in a general 'we may use your data to improve our services' line are exposed, and the fix is explicit, separable, opt-out (or opt-in) drafting.
The market standardized faster than most contracts updated. By 2024 the major providers had converged on user-owned outputs, a trailing-twelve-month liability cap, published deprecation notice windows, and a real GDPR Data Processing Agreement. A provider whose terms still read like 2022 boilerplate looks careless to the sophisticated developers and enterprise buyers who read these documents closely before they integrate.
The Legal Backbone
FTC Act Section 5, 15 U.S.C. § 45 (deceptive and unfair practices)
Section 5 prohibits 'unfair or deceptive acts or practices in or affecting commerce.' For an AI API, this is the statute that makes your capability claims and your data-handling promises legally enforceable against you. If your terms say the model does not train on customer inputs, or describe accuracy and safety the product does not deliver, the FTC can treat the gap as a deceptive practice. The Commission's 2023-2024 AI guidance made clear it reads marketing copy and terms together, so a promise you cannot keep in the contract is worse than no promise at all. Confirm the current posture of FTC AI enforcement before you rely on any specific representation.
Computer Fraud and Abuse Act, 18 U.S.C. § 1030
The CFAA is the federal anti-hacking statute, and it is the legal backbone of your acceptable use policy and your rate-limit enforcement. When your terms define authorized access and a developer exceeds it, scrapes around throttling, or uses the API to attack other systems, the CFAA can convert a contract breach into a federal violation. Section 1030(a)(5) specifically reaches malware and damage to protected computers, which is why a clean AUP bans using your model to develop malicious code. Note that the Supreme Court in Van Buren v. United States (2021) narrowed what 'exceeds authorized access' means, so define authorization carefully and do not assume every terms violation is a CFAA crime.
Copyright Act, 17 U.S.C. §§ 107, 201, 1201
Section 201(a) sets the default that the author owns a copyrightable work, which supports the now-standard clause giving the developer ownership of outputs rather than the provider; the work-made-for-hire doctrine only flips that with explicit language. Section 107 is the fair-use defense at the center of the training-data lawsuits, and it is unresolved, which is why your terms have to allocate infringement risk rather than assume the model's training was lawful. Section 1201 of the DMCA bars circumventing technological protection measures and bears on both how training data is gathered and how developers are restricted from defeating your access controls. The U.S. Copyright Office has separately said outputs with minimal human authorship may not be copyrightable at all, an open question your terms should not overstate.
GDPR, Regulation (EU) 2016/679, Articles 6, 9, 22, 28, and 82
If any prompt or output can contain EU personal data, the GDPR governs and it cannot be waived by contract. Article 6 requires a lawful basis for every processing activity, including training, and the EDPB's December 2023 AI guidance cast doubt on 'legitimate interest' or 'service improvement' as a basis for training on personal data. Article 9 imposes heightened protection on special-category data such as health, biometric, or political information that users may paste into a prompt. Article 22 governs automated decision-making where the API's output drives a decision about a person. Article 28 makes a signed Data Processing Agreement mandatory whenever you process personal data on a customer's behalf. Article 82 keeps the controller and processor liable for damages, which is why a flat liability cap has to yield to GDPR. These are heavy obligations; do not ship EU-facing terms without privacy counsel.
California privacy and consumer law: CCPA, Cal. Civ. Code § 1798.100 et seq., and CalOPPA, Bus. & Prof. Code § 22575
The CCPA gives California consumers the right to know what personal information you collect and how you use it, which reaches the use of their prompts to train your model. Section 1798.150 creates a private right of action with statutory damages for certain data breaches, an exposure your liability cap may not be able to limit. CalOPPA requires a conspicuous privacy policy that, for an AI API, must disclose whether inputs feed model training. These statutes set the minimum for U.S. consumers even when your customer is a business, because their end users may be Californians.
UCC Article 2 warranty and limitation rules (§§ 2-314, 2-719)
To the extent your API is treated as a good or hybrid service, UCC Section 2-314 implies a warranty of merchantability that the product will perform as described, which your terms typically disclaim. Section 2-719(3) lets you exclude consequential damages but only if the exclusion is not 'unconscionable,' and courts scrutinize one-sided modification and liability clauses in adhesion contracts. California's Discover Bank line of cases and the classic Tunkl v. Regents factors are the analysis a court will run if a developer argues your terms are too one-sided to enforce. Draft the disclaimers to be conspicuous and reasonable rather than maximal.
The seven clauses that decide whether your AI API terms hold up
Output ownership is the clause developers read first, and the market has a clear answer. Give the developer ownership of the outputs their prompts generate, and take back only a non-exclusive license to operate, secure, and (where lawful and disclosed) improve the service. This tracks Section 201(a) of the Copyright Act, where the default is that the author owns the work absent a written work-for-hire flip, and it matches where OpenAI, Anthropic, and Google all settled by 2024. A clause that vests outputs in the provider is both commercially toxic and increasingly indefensible. One caution belongs in the clause itself: outputs generated with minimal human input may not be copyrightable at all under current Copyright Office guidance, so grant ownership of whatever rights exist rather than warranting that a copyright exists.
Training rights deserve their own clearly labeled section, not a sentence smuggled into a privacy clause. State plainly whether you use customer inputs and outputs to train future models, and if you do, whether the default is opt-in or opt-out and how a customer exercises the choice. The market is split: Anthropic committed in writing that it does not use inputs or outputs to train new model versions, while OpenAI defaulted to collection with an enterprise opt-out. Under GDPR Article 6 and the EDPB's December 2023 guidance, 'we may use your data to improve our services' is not a safe basis for training on personal data, and under the CCPA you owe California consumers disclosure of exactly this use. Nothing in the terms draws a regulator faster than vagueness in this section.
The acceptable use policy is where your AUP does real legal work, because it defines authorized access for purposes of the Computer Fraud and Abuse Act. Prohibit illegal activity, intellectual-property infringement, harassment and unlawful discrimination, non-consensual intimate imagery and deepfake sexual content, child sexual abuse material, and the development of malware. Add the categories the market moved to after 2023: synthetic media that deceives, and election interference. Tie violations to a stated enforcement ladder, warning, throttling, suspension, termination, so the consequence does not blindside anyone. Keep the list specific. A court reading a CFAA claim wants to see that the developer knew the line they crossed.
Rate limits and service availability carry no statutory floor, so this is pure contract, and the trend is toward transparency. No federal law requires you to offer an SLA, and your warranty disclaimer typically negates the UCC's implied promise that the service works 'as described.' But sophisticated buyers now expect published token-per-minute or token-per-day limits, a documented throttling behavior rather than a hard cutoff, and recovery commitments of the kind Anthropic published. Put the mechanism in the terms by reference to your API documentation, reserve the right to enforce limits to protect the platform, and reserve any uptime promise for a separate enterprise SLA so your standard terms do not over-promise.
The right to change or deprecate models needs limits. UCC Section 2-208 and the case law on adhesion contracts disfavor unbounded unilateral modification rights, and under GDPR Article 5 a material change to model behavior can collide with a user's data expectations. The market answer is a published deprecation roadmap with a real notice window, 30 to 90 days depending on tier, rather than 'we may change anything at any time.' Reserve the right to modify the service, but commit to advance notice for material changes and breaking model sunsets. Developers build production systems on your endpoint; a silent swap that breaks their pipeline is how you lose them and how you invite a claim.
Indemnity should be reciprocal and precise, because Restatement (Second) of Contracts Section 357 and state law both demand unambiguous indemnity language. The developer indemnifies you for claims arising from their use of outputs and their AUP violations, the place where third-party IP claims on user-generated content land. In return, many leading providers now indemnify the customer for IP claims arising from the model's own training, a meaningful commercial signal. Carve out your own gross negligence and willful misconduct, and watch the state-law limits: California Civil Code Section 2782 voids indemnity for the provider's own negligence, so an overbroad clause is partly unenforceable in California anyway.
The limitation of liability has to be aggressive enough to be commercially viable and humble enough to survive. Cap total liability at the fees paid in the trailing twelve months, exclude indirect, consequential, special, and punitive damages, and then add the rider that the whole market adopted: 'except to the extent prohibited by applicable law.' That rider matters because GDPR Article 82 keeps you liable for data-protection damages regardless of the cap, the CCPA's statutory-damages provision may override it, and UCC Section 2-719(3) voids a consequential-damages exclusion that is unconscionable. Enterprise customers will negotiate the cap up to a multiple of annual fees; your standard terms set the floor.
When You Need This
You are launching an API, SDK, or hosted endpoint that lets outside developers send requests to your AI model and receive generated text, images, audio, code, or structured data.
You are wrapping or reselling a third-party model (OpenAI, Anthropic, Google, an open-weight Llama deployment) and need your own terms to sit on top of theirs, with your obligations flowing down from the upstream provider's terms.
Your model can receive prompts that contain personal data from EU or UK residents, which triggers a mandatory Data Processing Agreement under GDPR Article 28 alongside these terms.
You are signing up enterprise customers who will redline output ownership, the liability cap, the training-data position, and the deprecation notice window before they integrate.
You are updating 2022-era terms that grabbed output ownership for the provider, buried training rights in a privacy clause, or reserved an unbounded right to change the model, all of which now read as out of step with the market and the regulators.
You operate an open-weight or downloadable model and need an acceptable use policy and community license that restrict harmful uses (deepfake sexual content, election interference) even though you cannot enforce rate limits on self-hosted deployments.
How to Fill Out AI API Terms of Service
1. Define the parties, the service, and the document hierarchy
Name the provider entity and define 'Customer' to cover both the account holder and the developers acting under it. Describe the service precisely: which models, which endpoints, and what 'Input' and 'Output' mean. Then state the order of precedence, because an AI API terms of service rarely stands alone. Specify that an executed enterprise order form or Data Processing Agreement controls over these terms, that these terms control over the API documentation, and that the acceptable use policy and privacy policy are incorporated by reference. Getting the hierarchy right here prevents the conflict fights later.
2. Set output ownership and the license back to the provider
State that, as between the parties, the Customer owns the Outputs generated from its Inputs, and grant the provider only a non-exclusive, limited license to host, transmit, secure, and (if and only if disclosed and lawful) improve the service. Add the honest caveat that outputs may not be independently copyrightable under current U.S. Copyright Office guidance, and that the provider warrants no specific intellectual-property rights in any Output. Avoid any work-made-for-hire language that would flip Section 201(a) ownership back to you.
3. Write the training-data clause as its own labeled section
Decide your position and state it without ambiguity. Either commit that you do not use Inputs or Outputs to train models (the Anthropic posture), or disclose that you do and specify whether the default is opt-in or opt-out, how the customer changes it, and the retention period. For any EU-facing offering, anchor the lawful basis under GDPR Article 6 and confirm with privacy counsel that 'service improvement' alone is not your basis. Add the CCPA-required disclosure of this use for California consumers. This section should be findable in five seconds, not hidden.
4. Draft the acceptable use policy and enforcement ladder
List prohibited uses in concrete terms: illegal activity, IP infringement, harassment and unlawful discrimination, non-consensual intimate imagery, CSAM, malware development, deceptive synthetic media, and election interference. Tie the list to authorized access language so a violation maps to the Computer Fraud and Abuse Act, but define authorization carefully in light of Van Buren. Then state the enforcement ladder, warning, throttling, suspension, and termination, and reserve the right to act immediately for severe violations such as CSAM.
5. Specify rate limits, availability, and the change/deprecation regime
Reference your published token-per-minute or token-per-day limits in the API documentation rather than freezing numbers in the contract, reserve the right to throttle to protect the platform, and disclaim any uptime warranty in the standard terms while pointing enterprise customers to a separate SLA. For model changes, replace 'we may change anything at any time' with a commitment to advance notice for material changes and a deprecation window of 30 to 90 days for model sunsets, ideally backed by a published roadmap.
6. Build reciprocal indemnity and the liability cap
Have the Customer indemnify the provider for claims arising from its Outputs and AUP violations, and consider offering a provider-side IP indemnity for claims arising from the model's training, which is now a competitive differentiator. Cap total liability at the trailing twelve months of fees, exclude indirect and consequential damages, and add the 'except where prohibited by applicable law' rider so the cap yields to GDPR Article 82 and statutory-damages regimes. Carve out gross negligence and willful misconduct, and remember California Civil Code Section 2782 voids indemnity for your own negligence.
7. Attach the privacy stack: privacy policy, DPA, and sub-processor list
Incorporate a privacy policy that satisfies CalOPPA and GDPR Article 13, and for any EU personal data, attach a Data Processing Agreement under Article 28 with a sub-processor list, data-location commitments, retention and deletion terms, and data-subject-rights handling including the Article 17 right to erasure. Do not try to fold these into the body of the terms; regulators expect separable, dedicated documents. Most providers underbuild this step, and it is the one that draws regulatory complaints.
8. Add governing law, dispute resolution, modification, and review the whole stack with counsel
Choose governing law and a dispute-resolution mechanism, set a reasonable notice procedure for amending the terms (silent retroactive changes invite an unconscionability challenge), and add a survival clause for the ownership, indemnity, and liability sections. Then stop and have qualified counsel review the full stack against current FTC enforcement posture, the live status of Authors Guild v. OpenAI and Getty v. Stability AI, and your actual data flows. This page is not legal advice, and AI law in 2026 is moving faster than any template can track.
Key Terms Defined
- Input and Output
- The 'Input' is what the developer or end user sends to the API (the prompt, files, parameters). The 'Output' is what the model generates in response. The terms have to define both precisely because ownership, training rights, and liability all turn on which is which. Conflating them is a common drafting error.
- Acceptable Use Policy (AUP)
- The companion document that lists what developers may not do with the API: illegal activity, IP infringement, deepfake sexual content, malware, and the like. It defines authorized access for Computer Fraud and Abuse Act purposes and is usually incorporated by reference into the terms rather than written into the body.
- Data Processing Agreement (DPA)
- A separate, GDPR Article 28-mandated contract between the customer (controller) and the API provider (processor) that governs how personal data in prompts and outputs is handled: location, retention, deletion, sub-processors, and data-subject rights. Required whenever EU personal data flows through the API.
- Lawful basis
- Under GDPR Article 6, the legal ground that permits each processing activity. For training a model on personal data, the European Data Protection Board's 2023 guidance signaled that 'service improvement' or 'legitimate interest' is often insufficient, and a stronger basis such as consent may be required.
- Limitation of liability cap
- The clause capping the provider's total monetary exposure, market-standard at the fees paid in the trailing twelve months, with exclusions for indirect and consequential damages. The cap must yield where law forbids it, including GDPR Article 82 data-protection liability and certain state statutory-damages schemes.
- Deprecation notice
- The advance-warning commitment a provider gives before retiring or materially changing a model, typically 30 to 90 days. It exists because production systems depend on stable endpoints and because unbounded unilateral change rights are disfavored in adhesion contracts under UCC Section 2-208 and related case law.
Related Documents
AI API Terms of Service vs. Website Terms of Use
Website terms of use govern how visitors interact with a site: account rules, prohibited conduct, and IP in the site's own content. They do not address a machine generating new content, who owns those generations, or whether user submissions train a model. An AI API terms of service is a developer-facing commercial contract with output-ownership, training-rights, indemnity, and liability machinery that website terms simply lack. If you run a site and offer an API, you need both, and the API terms should control for anything touching the model.
AI API Terms of Service vs. Privacy Policy
A privacy policy is a disclosure document required by CalOPPA and GDPR Article 13: it tells users what data you collect and how you use it, but it does not create the binding commercial bargain. The AI API terms of service is that bargain, and it references the privacy policy rather than replacing it. The privacy policy is also where you make the CCPA-required disclosure that customer inputs may train your model, a fact the terms then govern as a contractual right. The two documents must not contradict each other, because the FTC reads them together and treats a gap between them as deception.
AI API Terms of Service vs. Data Processing Agreement
The terms of service set the overall commercial relationship; the Data Processing Agreement is the narrow, GDPR Article 28-mandated contract that governs personal data the provider processes on the customer's behalf. The DPA addresses sub-processors, data location, retention, deletion, and data-subject rights at a level of detail the terms do not. They are complementary: the terms cannot satisfy the Article 28 requirement, and the DPA does not govern output ownership or liability. Any provider touching EU personal data needs both, with the DPA typically controlling for data-protection conflicts.
AI API Terms of Service vs. End User License Agreement (EULA)
A EULA licenses installed or downloadable software to an end user and restricts copying, reverse engineering, and redistribution. It is the right instrument for an open-weight model a customer downloads and runs locally, where there is a license to grant and no live service to govern. An AI API terms of service governs a hosted service the customer calls remotely, where there is no software to license but there are rate limits, availability, training rights, and outputs to allocate. Providers that ship both a hosted API and downloadable weights often need both documents.
Legal Authorities & Sources
This page is grounded in primary law. The statutes and official resources below are the authorities behind the guidance above. Verify the current text of any statute before relying on it.
- FTC Act and laws enforced by the Federal Trade Commission (15 U.S.C. § 45)
- Computer Fraud and Abuse Act, U.S. Department of Justice (18 U.S.C. § 1030)
- U.S. Copyright Office, DMCA and Section 1201
- U.S. Copyright Office, Artificial Intelligence guidance
- General Data Protection Regulation, full text (Regulation (EU) 2016/679)
- European Data Protection Board, Guidelines on AI and data protection
- California Attorney General, California Consumer Privacy Act (CCPA)
Frequently Asked Questions
Create your AI API Terms of Service in minutes.
Answer a few questions and download a clear, attorney-drafted document that cites the controlling law and is ready to sign.