API Terms of Use.

Scope of the licence to use the API

The grant clause needs to specify exactly what a developer can do — build applications that call the API, but not resell API access itself, scrape data beyond what's returned by legitimate calls, or use the API to build a directly competing product. We tailor the restrictions to your actual commercial concerns rather than importing generic language that either under-protects the platform or is so broad it deters legitimate integration.

Rate limits, fair use and service changes

We include a right to impose and vary rate limits, throttle or suspend access for excessive or abusive use, and change the API (including deprecating versions) on reasonable notice. Developers building commercial products on the API need enough certainty to plan around these changes, so we typically commit to a minimum notice period for breaking changes rather than reserving an unqualified right to change anything at any time.

Data ownership and use of data passed through the API

Where the API transmits customer or user data between the platform and third-party developers, the terms need to be explicit about who owns that data, what the developer is permitted to do with it, and — where personal information is involved — that the developer takes on its own obligations under the Privacy Act 1988 (Cth) rather than assuming those obligations sit solely with the platform. We also restrict developers from retaining or reusing data beyond what's needed to provide their integration, particularly where the platform's own customers haven't consented to broader use.

Suspension and revocation of access

API access needs a fast, low-friction suspension mechanism for security incidents, abuse or breach of the rate limits and usage restrictions — distinct from the slower, cure-period-based termination process suited to a commercial contract. We draft a graduated response: warning, throttling, then suspension, with immediate revocation reserved for security threats or serious breaches like unauthorised data use.

Liability and no guarantee of availability

Unless you're selling the API under a paid enterprise agreement with its own service levels, we disclaim any uptime guarantee for free or standard-tier API access and cap liability accordingly, so developers build with appropriate resilience (retries, caching, fallback behaviour) rather than architecting their product around an assumption of continuous availability you haven't actually promised.

What the fixed fee covers

• Standalone API terms of use document
• Registration, API key and permitted use clauses
• Rate limiting, versioning and deprecation notice provisions
• Data ownership and third-party developer privacy obligations
• Suspension and revocation mechanism
• Liability and availability disclaimers

Mistakes we see

• Relying on general platform terms with no API-specific rate limit or deprecation provisions
• No minimum notice period for breaking API changes, breaking developer integrations without warning
• Ambiguity over who owns and can use data passed through the API
• No graduated suspension mechanism, forcing an all-or-nothing termination response to abuse
• Promising uptime commitments for free-tier API access with no commercial basis to support them

Who this is for

• Platforms opening an API to third-party developers
• SaaS businesses building a developer ecosystem or app marketplace
• Fintech and data businesses exposing data via API integrations
• Businesses monetising API access through paid tiers

Frequently asked questions

Do free and paid API tiers need different terms?

Generally the core legal terms stay the same, with a schedule or order form addressing rate limits, uptime commitments (if any) and support levels specific to the paid tier. We build the base document to flex across tiers rather than drafting entirely separate agreements.

Can we cut off a developer's access without notice?

For genuine security incidents, serious breaches or fraud, yes — the terms should allow immediate suspension. For lower-level issues like exceeding rate limits, a graduated response with warning and throttling first protects the relationship with developers who aren't acting maliciously.

Who's responsible for privacy compliance if personal data flows through our API?

Both parties generally have obligations under the Privacy Act 1988 (Cth), but the terms should clearly allocate responsibility for what happens to the data once it leaves your platform and reaches the developer's systems, rather than leaving developers assuming your compliance covers their handling too.

Can we change API pricing or terms once developers have built on it?

You should reserve the right to, but with adequate notice — the longer a developer has been integrated and reliant on the API, the more disruptive an abrupt change becomes, and reasonable notice periods reduce both legal risk and reputational fallout.

Should the API terms include an IP licence back to us over integrations built on our API?

Only if you have a genuine commercial reason to want visibility or rights over what's built — most platforms don't need this and it can deter developer adoption. We tailor this clause to your actual ecosystem strategy rather than including it by default.