API terms of use: what they must include

API terms of use are a contract, not documentation

Service page: Digital commerce and AI lawyer: terms, privacy and direct mailing.

An application programming interface (API) is the way one system accesses the service of another system. Once you have opened an interface to parties outside the organization (partners, business customers or a developer community), you have created an access channel to your data and infrastructure. The document that regulates this channel is not technical documentation but a contract.

There is nothing special about how the contract is made: offer and acceptance under the Contracts (General Part) Law, 5733-1973 can also come together through electronic approval and actual use of an access key. What is special is the content, and the fact that in most cases it is a standard text that one party wrote in advance.

Are API terms a standard-form contract?

A “standard-form contract” is defined in section 2 of the Standard Contracts Law as the text of a contract whose terms, all or some of them, were set in advance by one party so that they serve as terms for many contracts between that party and persons who are not specified in number or identity. Interface terms of use that are published on a website and apply to everyone who registers meet this definition almost always.

So section 5 of the Law applies: a term that denies or limits the customer’s right to go to court is void; a term that releases the supplier from liability for bodily injury or for a malicious act is void. The presumptions of unfairness in section 4 also apply. They include: an exemption from liability imposed by law, or an unreasonable limitation of it (paragraph 1); an unreasonable right to cancel, suspend or change material obligations (paragraph 2); a one-sided price change after the contract was made (paragraph 4); denial of a right or remedy that the customer has by law (paragraph 6); an arbitration clause (paragraphs 8–10); and contracting out of the provisions of the law on the place of jurisdiction (paragraph 9).

So “we may close access at any time, for any reason, without notice” is not a strong clause. Wording that holds up distinguishes between reasons: a breach of the usage policy or a security risk justifies immediate suspension; a commercial change justifies advance notice within a defined period.

Defining permitted use, and prohibited use

This is the clause from which most disputes arise. What was not expressly prohibited is very hard to prohibit after the fact:

• Scope of use: for which purposes the data may be used, and whether it may be shown to the developer’s end users.
• Competing product: whether the developer may use the interface to build a service that competes with the operator. If not, define what competition is.
• Transfer to a third party: whether the access may be transferred, sold, or built into a product that is sold on.
• Harvesting and accumulation: whether the data may be stored permanently and used to build an independent database, or only used on a one-off basis.
• Rate limits: the number of calls per second, per minute and per day, and the result of exceeding them: slowing down, an extra charge or blocking. A limit that was not set in the contract is hard to enforce after the fact.

A point that is forgotten: the technical documentation itself. In most agreements it is brought in by reference (“subject to the documentation published from time to time”), and so it becomes part of the contract, with all that this implies. If you adopt a structure like this, keep dated versions of the documentation, because in a dispute the question will be what exactly was allowed at the relevant time. The same rule applies to helper libraries and development kits: the license that applies to them, and sometimes also open-source licenses built into them, become part of the contractual picture.

Availability, versions and deprecation

A developer who has built a whole product on an outside interface is exposed to two risks: that the interface goes down, and that it changes. The agreement should deal with each separately. On availability: an availability target, how it is measured, and a real remedy, not just a token credit. On changes: a clear version policy, a commitment to a minimum support period for an existing version, and a timetable for advance notice before a capability is deprecated.

The sudden deprecation of a central capability is exactly the situation in which the presumption of unfairness in section 4(2) of the Standard Contracts Law is relevant: an unreasonable right of the supplier to change material obligations under the contract. On the other hand, an operator that set a reasonable version policy in advance, published a timetable and gave notice accordingly is in a much better position.

Access keys, misuse and the Computers Law

An access key is a means of identification, and it often leaks: it is saved in open-source code, passed between employees, or stolen. The agreement should state expressly: a duty to keep the key confidential, a ban on sharing it, a duty to give immediate notice of a suspected leak, and responsibility for use made with the key until the time of the notice.

Beyond the contract, a criminal layer applies. Section 4 of the Computers Law, 5755-1995 provides that a person who unlawfully penetrates computer material held in a computer is liable to three years’ imprisonment, and section 5 provides that such penetration in order to commit another offense carries five years. Section 2 prohibits disrupting the proper operation of a computer or interfering with its use, and section 6(b) prohibits distributing or passing on a password or access code so that one of the prohibited acts is carried out. Using an interface beyond the authorization, or passing a key to a third party so that it makes prohibited use of it, can fall within these sections.

The link between the layers is practical: the more precisely the authorization is defined in the contract, the easier it is to show that a certain act was done “unlawfully” or beyond the authorization.

Suspected use beyond authorization or a leaked key: what to do

1. Suspend or replace the key, under the suspension mechanism set in the agreement.
2. Document the event: the controller of a database must document every event that raises a concern of use of the information without authorization or beyond authorization (regulation 11(a) of the Protection of Privacy Regulations (Data Security)).
3. Keep the access logs. In a database at a medium or high security level, they are kept for at least 24 months (regulation 10(d)).
4. Check whether it is a “severe security incident” as defined in regulation 1. If so, report it to the Privacy Protection Authority immediately (regulation 11(d)).
5. Send the developer a written demand to stop the use and to delete the information that was harvested, in line with the agreement.
6. When unlawful penetration or disruption is suspected, consider a police complaint under the Computers Law (sections 2 and 4).

Personal information that passes through the interface

If information about people flows through the interface, data protection law comes into the picture. Under the Protection of Privacy Law, 5741-1981, as amended by Amendment No. 13, which came into force on 14 August 2025, a controller is the person who determines the purposes of the processing, and a holder is an outside party that processes information on the controller’s behalf. In an interface where the developer processes information on behalf of the operator, the developer is a holder. In an interface where the operator provides a service to the developer on information of the developer’s customers, the relationship can be reversed. Setting the roles expressly in the agreement saves a later dispute.

When the engagement involves giving access to a database, regulation 15 of the Data Security Regulations requires the agreement to set: the information that may be processed and the purposes of use; the systems that may be accessed; the type of processing; the term of the engagement and how the information is returned and destroyed at its end; how the security duties are implemented; a confidentiality undertaking by those with access rights; rules for engaging a subcontractor; and reporting duties, at least once a year, plus notice to the database controller in the event of a security incident. The same requirement applies to every cloud or service agreement.

Liability: who bears the damage, and toward whom

In an open interface there are three circles of damage, and each has its own arrangement. The first circle is damage the developer causes the operator: a load that brings the service down, use of the data beyond what was allowed, or a breach that originates on the developer’s side. Here you need an undertaking to indemnify from the developer, defined in scope and with a cap, and alongside it a right of immediate suspension.

The second circle is damage the operator causes the developer: downtime, corrupted data or a sudden disconnection. Here a broad exemption is usually offered, and it is examined under the Standard Contracts Law: a sweeping exemption falls within the presumption of unfairness in section 4(1), and an exemption from liability for bodily injury or for a malicious act is void under section 5(b). A proportionate cap that expressly excludes malice, breach of confidentiality and breach of data security duties is much more robust.

The third circle is damage to a third party: the developer’s end user who is harmed by a fault or a leak. In this situation both parties can be sued together, and the internal question is how liability is split between them. A mutual indemnity clause that divides the risk by the source of the failure, and not by who the claimant is, saves a second round of litigation. It is also worth setting a mechanism for cooperation in the defense: who manages the proceeding, who bears the costs and who may settle.

In addition, when the interface transfers personal information, it is worth requiring suitable insurance and defining its scope and how long it stays in force, including after the engagement ends. Exposure in this area often comes to light late.

Intellectual property, data and outputs

Three separate ownership questions, which should not get mixed up. The first: the rights in the interface itself, the documentation and the helper libraries. They stay with the operator, and the developer receives a limited, non-exclusive and non-transferable license to use them. The second: the data transferred through the interface. Who owns it, and what may be done with it after the engagement ends. The third: the outputs the developer creates on top of the interface. The developer’s app belongs to the developer, but it may contain components that come from the operator.

Another clause worth including: use of the name and trademarks. Developers tend to show the operator’s name to signal reliability, and operators tend to show their customers. It is better to settle in advance what may be shown, in what context, and when the permission expires.

Termination, changes and advance notice

A reasonable interface agreement distinguishes between three termination situations: termination initiated by the developer; termination initiated by the operator for commercial reasons, which requires reasonable advance notice; and immediate suspension because of a breach, a security risk or a demand from an authority. For each situation, set what happens to the data already transferred: deletion, return, or limited continued use.

On changing the terms: the common wording “continued use constitutes consent to the updated terms” is examined, in a standard-form contract, against the presumptions of unfairness. A balanced version sets advance notice, distinguishes between a technical change and a material change, and gives the developer a window of time to end the engagement without a penalty if the change is material.

FAQ

Are API terms of use binding if you only ticked a box?

Yes, as a rule. Consent can come about through electronic approval and actual use of the access key. However, when it is a standard text that the stronger party wrote in advance, certain terms in it can be canceled or changed under the Standard Contracts Law. A term that denies the right to go to court is void from the outset.

What happens if a developer exceeds the rate limits?

If the limits and the result of exceeding them were set in the contract, the result that was set applies: slowing down, an extra charge or suspension. If they were not set, the operator is left with general arguments only, and sometimes with an argument under the Computers Law about interfering with the use of a computer. That argument is harder to prove.

Can a developer’s access be shut off without notice?

It depends on the grounds and the wording. Immediate suspension because of a breach or a security risk is reasonable. A commercial disconnection without notice, especially when the developer built a product on the interface, is examined under the presumption of unfairness in section 4(2) of the Standard Contracts Law. It is better to define grounds and notice periods in advance.

Is a separate privacy arrangement needed for the interface?

If information about people passes through it, yes. You need to set who is the controller and who is the holder, and include the subjects listed in regulation 15 of the Protection of Privacy Regulations (Data Security): the scope of processing, the systems, the type of operations, the term of the engagement, return and destruction of the information, implementation of the security duties, confidentiality, subcontractors, and reporting a security incident.