What should my API terms of use cover?
Written by For Founders Law, a Toronto firm licensed by the Law Society of Ontario. About us
Short answer
API terms set the rules for developers who build on your platform: who gets access and keys, what they may build, rate limits, what they can do with data that flows through the API, and when you can change, suspend or shut it down. They usually sit alongside your main terms of service or customer agreement, with extra clauses on data, attribution and liability, because a developer uses your service to build something you haven't seen, for users you don't know.
Your terms of service are written for people using a finished product. API terms are written for developers, agencies and partners who connect their own software to yours. The questions are different: how much they can call, what they can store, what they can resell and what happens to their integration when you change things.
Do I need separate API terms?
Usually, once outside developers can get keys. You can put API rules in your main terms of service or SaaS agreement, but a public or partner API is easier to manage with its own developer terms that the main agreement incorporates by reference. Enterprise customers who integrate with you may still negotiate API terms inside their customer contract.
What should API terms cover?
| Term | What it should say |
|---|---|
| Access and keys | Who may register, that keys are confidential, and that the developer is responsible for all use of its keys |
| Licence | A limited, non-exclusive, revocable licence to use the API to build the developer’s application, and nothing more |
| Permitted and prohibited uses | No scraping beyond the API, reverse engineering, building a competing product, reselling access, or circumventing limits. An acceptable use policy can sit alongside |
| Rate limits and quotas | Published limits, and your right to throttle or suspend for excess use |
| Data | What the developer may store, for how long, whether it may combine or sell it, and deletion when access ends |
| Privacy and security | Who is responsible for consent, security safeguards, and breach notice |
| Branding and attribution | Whether developers may use your name and logo, and how |
| Changes and versioning | Notice before breaking changes or deprecation, and your right to change or discontinue the API |
| Fees | Free tier, paid tiers, overage charges and payment terms, if any |
| Suspension and termination | When you can cut off access immediately, and what survives |
| Warranties and liability | The API is provided as is, with a cap on liability. See limitation of liability |
| Indemnity | The developer covers claims arising from its application and its users. See indemnity clauses |
| Governing law | Which law and courts apply |
How do I handle personal information through an API?
It depends on whose information it is and who decides what happens to it. If a developer processes personal information for you, PIPEDA keeps you responsible for it: under Principle 4.1.3 of Schedule 1, an organization is responsible for personal information transferred to a third party for processing, and must use contractual or other means to protect it. That calls for a data processing agreement.
If your API sends your users’ personal information to a developer’s own app, that’s a disclosure, and under Principle 4.3 the knowledge and consent of the individual are required for collection, use or disclosure, except where inappropriate. Build the consent step into the connection flow (for example, an authorization screen that says what the app will receive) and require developers to have their own privacy policy.
Can I change or shut down my API?
Yes, if your terms say so, and developers will expect notice. Reserve the right to change, suspend or discontinue the API, commit to a notice period for breaking changes and deprecations if you want developers to rely on you, and keep the right to act immediately for security issues, abuse or legal requirements. Paying partners often negotiate longer notice and transition help.
How do developers accept the terms?
The same way as other online terms: a clear step where the developer agrees before getting keys, with the terms one click away. Keep a record of who accepted which version. See are clickwrap agreements enforceable in Canada.
What’s different for AI APIs?
An AI API raises questions a data API doesn’t. Your terms should deal with:
- Inputs and outputs. Who owns them, and whether you use developers’ inputs to train or improve models.
- Model use. Whether developers may use outputs to train a competing model.
- Downstream users. That developers pass your usage policies on to their own users and are responsible for their application’s use cases.
- Disclosure. Whether developers must tell their users that content is AI-generated. See do I have to tell people my product uses AI.
See what your AI product terms should cover.
Who owns integrations built on my API?
Usually the developer owns its own application, and you own the API, your documentation and your platform. A computer program is a literary work under section 2 of the Copyright Act, and copyright only moves by a signed written assignment under section 13. If you want rights in something a partner builds, such as a connector you’ll list in your marketplace, put it in the agreement. Ask for feedback rights too, so you can use developers’ suggestions freely.
What to do next
API terms are often prepared alongside your other customer terms. Our terms of service fee starts at $500, a SaaS or master services agreement starts at $920, and AI product terms start at $760. If a partner has sent you their API or developer agreement, we review it as a contract review, starting at $400.
This guide is general information about Ontario and Canadian law, not legal advice for your situation. To talk through your API, book a free 15-minute consult.