API Agreements in New Zealand: Key Terms for SaaS and Technology Businesses

If your SaaS product depends on a third party API, or if other businesses connect into your platform, the contract behind that connection matters more than most founders expect. A lot of problems start when a business accepts standard API terms without checking data rights, assumes uptime promises are stronger than they really are, or relies on a sales conversation instead of the written agreement. Those mistakes can become expensive once your product is live and customers depend on the integration.

An API agreement should do more than describe access to software. It should set clear rules about permitted use, service levels, security, liability, payment, suspension rights and who carries the risk if something breaks. For New Zealand businesses, privacy obligations, fair dealing in marketing, and practical contract drafting all matter.

This guide explains what an API agreement means in practice, the legal issues to check before you sign, where SaaS and technology businesses usually get caught, and the clauses worth negotiating before you accept the provider's standard terms.

Overview

An API agreement is the contract that governs how one party can access, use, integrate with, and rely on an application programming interface. For New Zealand SaaS and technology businesses, the real value of the agreement is that it allocates risk before your product team builds around someone else's system or opens your own platform to external developers.

A short set of online terms can still create major legal and commercial obligations. The key is to make sure the agreement matches how the API will actually be used in your business.

• Define exactly what the API can be used for, and what use is prohibited.
• Check who owns input data, output data, usage data and any derived analytics.
• Confirm service levels, maintenance windows, support response times and outage remedies.
• Review privacy, security and cross border data handling obligations.
• Look closely at fees, usage caps, overage charges and the provider's right to change pricing.
• Check whether the provider can suspend or terminate access on short notice.
• Review warranties, liability caps, indemnities and excluded losses.
• Make sure the agreement covers intellectual property, confidentiality and compliance obligations.
• Confirm whether subcontractors or downstream customers can use the API through your product.
• Check dispute resolution, governing law and whether New Zealand law is a practical fit.

What API Agreement Means For New Zealand Businesses

An API agreement is not just a technical document, it is a commercial contract that can affect your product roadmap, customer promises and legal exposure.

For a New Zealand business, this often comes up in two common scenarios. The first is where your software relies on a payment, messaging, identity, logistics, accounting or AI API provided by someone else. The second is where your own platform exposes APIs to customers, resellers or development partners.

In both cases, the agreement needs to align with how revenue is earned and how risk flows through the business. If your customers pay you for a feature that depends on a third party API, you may still be responsible to your customers even if the upstream provider caused the outage. That is why the written terms matter before you sign and before you make promises in your own customer terms.

Why API terms matter commercially

The legal issue is often less about access itself and more about dependency. Once your engineers build deeply into an API, changing provider can be slow and expensive. That gives the provider leverage if the agreement allows unilateral changes to fees, rate limits or technical requirements.

For SMEs, this can affect margins, service quality and customer churn. A cheap integration can become costly if usage based charges rise faster than your own pricing model. A broad right to suspend access can also leave you scrambling to explain an outage to customers.

How New Zealand law fits in

Most API agreements are ordinary commercial contracts. In New Zealand, general contract principles apply, and the wording of the agreement will usually carry the most weight. Online click-through terms can still be enforceable if accepted properly.

Privacy also matters where personal information moves through the API. If your business collects, stores, discloses or processes personal information, the Privacy Act 2020 may apply. That means you need to understand what data is being shared, why it is being shared, where it is stored, and what safeguards are in place.

Marketing and customer representations matter too. If you describe an integration as secure, reliable, real time or fully compliant, those claims should be accurate. The Fair Trading Act 1986 can be relevant if advertising or sales statements are misleading.

Where the API supports services provided to business customers, you should also think about how your own service agreement or customer contracts deal with outages, third party dependencies and limitation of liability. The main point is simple: your upstream API agreement and your downstream customer contracts should not conflict.

When a simple online sign up is not enough

A standard sign up flow may be fine for low risk tools, but higher value or business critical integrations often need negotiated terms. That is especially true where the API handles sensitive customer data, powers a key product feature, or forms part of a regulated or high trust service.

Founders often accept standard terms because the integration team wants to move quickly. This is where businesses get caught. If the provider's terms let them change functionality at any time, disclaim all warranties, and cap liability at a month of fees, your business may be carrying almost all of the risk.

Legal Issues To Check Before You Sign

The safest time to fix an API contract is before your developers build around it and before you rely on a verbal promise from a sales rep.

Scope of access and permitted use

The agreement should say exactly what you can do with the API. That includes which applications, products, affiliates, environments and users are covered. If you plan to let your own customers access functionality powered by the API, the contract should allow that.

Check for limits such as:

• internal business use only
• no resale or no white labelling
• restrictions on caching, storing or reproducing API responses
• prohibitions on reverse engineering or benchmarking
• limits on use in testing, staging or production environments
• territorial restrictions or prohibited industries

If the agreement is vague, you may pay for access but still be in breach once your product scales.

Data rights and ownership

Data clauses are often the most commercially important part of an API agreement. The contract should separate different categories of data instead of referring to all information as if it belongs to one side.

At a minimum, the agreement should deal with:

• your data that you send through the API
• customer personal information
• the provider's API documentation and technical materials
• output generated by the API
• metadata, logs and usage analytics
• de-identified or aggregated data used for service improvement

You should know whether the provider can use your data to train models, improve products, generate benchmarking insights or support other customers. If that is not intended, the contract should say so clearly.

Privacy and security obligations

If personal information is involved, privacy compliance cannot sit in the background. You need clear obligations around collection, use, storage, disclosure, breach response and deletion.

Points worth checking include:

• whether the provider is acting on your instructions or using data for its own purposes
• where data is stored and whether it is transferred overseas
• minimum security standards, such as encryption, access controls and audit logging
• timeframes for notifying security incidents or privacy breaches
• rights to request deletion or return of data at the end of the arrangement
• whether subcontractors can access the data

If the API provider stores information outside New Zealand, that does not automatically make the arrangement unlawful, but it does mean you should check the privacy position carefully and make sure your own privacy notice and disclosures are accurate.

Service levels, support and change management

If the integration is business critical, uptime promises should be written down. Marketing claims about reliability are not enough.

The contract should address:

• service availability targets
• planned maintenance windows
• incident severity levels and support response times
• service credits or other remedies for major outages
• notice periods for material API changes or version deprecation
• how long old versions will be supported

This is especially important for SaaS businesses that offer service commitments to their own customers. If your provider can materially change endpoints with minimal notice, your support team may carry the operational pain.

Fees, billing and usage limits

Usage based pricing can look simple at first and become difficult once customer numbers grow. The agreement should explain how usage is measured, when charges arise, and what happens if you exceed limits.

Check for:

• monthly minimum commitments
• overage pricing and how it is calculated
• audit rights for usage verification
• automatic fee changes or annual increases
• suspension rights for disputed invoices
• refund rules if the API is unavailable

If revenue depends on predictable margins, unclear API charging terms are a real commercial risk. You may also want your accountant or tax adviser to review the pricing structure from a financial perspective.

Intellectual property and licence terms

The API provider will usually keep ownership of its platform, code, documentation and branding. That is standard. The real issue is whether your business receives a licence broad enough to operate your product as intended.

You should also check whether the provider receives any rights over your application, feedback, connectors or derivative tools. A broad feedback clause can sometimes allow use of your suggestions without restriction, which may be acceptable, but it should be understood before you sign.

Liability, indemnities and risk allocation

Liability clauses show who absorbs the loss if something goes wrong. This is where standard provider terms are often most one sided.

Review:

• the overall cap on liability
• whether the cap is tied to a very small amount of fees
• which claims are excluded from the cap
• whether indirect or consequential loss is excluded
• who gives indemnities for IP infringement, data misuse or third party claims
• whether the provider excludes liability for outages, data loss and security issues

A liability cap is not automatically unreasonable, but it should make sense for the value of the deal and the potential harm if the API fails.

Suspension, termination and exit

You need a realistic exit path before you become technically dependent on the service. Some agreements allow immediate suspension for broad reasons, including suspected misuse or reputational concerns.

Look for clauses dealing with:

• termination for convenience and required notice
• termination for breach and cure periods
• immediate suspension rights
• data export support on exit
• transition assistance
• what happens to prepaid fees and accrued usage charges

If the API is central to your product, losing access overnight may cause much bigger losses than the contract compensation available.

Common Mistakes With API Agreement

The most common API contract mistakes happen when a business treats technical integration as separate from legal and customer risk.

Accepting standard terms without mapping the customer journey

Founders often focus on getting the integration working and overlook how the API affects promises made to paying customers. If your app advertises instant sync, guaranteed delivery or secure verification, those claims need to match the provider's actual commitments.

Where there is a gap, fix it in one of two places: negotiate the API agreement, or adjust your own customer contracts and product claims.

Ignoring data use beyond the core service

A provider may need access to process requests, but that does not always mean they should be free to use the data for product training, analytics sharing or unrelated commercial purposes. Businesses often miss this because the clause is buried in technical or privacy language.

This matters even more where customer trust is part of your value proposition. If your platform handles health, financial, education or workforce data, clients will expect clear boundaries.

Assuming the provider's liability reflects the real risk

A very low liability cap is common in online software terms. The mistake is assuming it will be negotiable later, after your product depends on the API. Once you are locked in technically, your leverage usually drops.

Check the risk early, particularly if an outage could cause customer refunds, breach claims, reputational damage or operational disruption.

Forgetting downstream contract alignment

Your business may promise service standards or data rights to customers that your API provider does not support. That mismatch creates a contract gap.

For example, your customer terms might promise high availability, but your upstream provider offers no uptime commitment. Or your customer contract might allow data portability, while the API provider gives limited export rights. Those issues should be aligned before you sign.

Relying on informal assurances

Sales conversations are useful, but they do not replace the contract. A founder may be told that pricing will remain stable, that deprecation will come with plenty of notice, or that data is never used for model training. If the written agreement says otherwise, the written clause usually matters more.

Ask for key promises to be included in the agreement, statement of work, order form or written policy incorporated into the contract.

Overlooking governing law and dispute mechanics

Many API providers use offshore terms with foreign governing law and overseas dispute forums. That may be manageable for low value tools, but it becomes less attractive for important integrations.

A New Zealand business should at least understand where disputes would be handled, what notice requirements apply, and whether the contract forces arbitration, short limitation periods or provider friendly procedures.

Not planning for growth

An API arrangement that works for 100 users may not work for 10,000. Rate limits, user restrictions, audit rights and pricing tiers can become painful only after traction arrives.

The better approach is to stress test the contract against your growth plan. Think about enterprise customers, reseller arrangements, overseas customers, white labelled products and higher security expectations.

FAQs

What is an API agreement?

An API agreement is a contract that sets the rules for accessing and using an application programming interface. It usually covers licence scope, data use, security, service levels, fees, intellectual property, liability and termination.

Do New Zealand SaaS businesses need a written API agreement?

In practice, yes. Even if the provider offers standard online terms, you still need written terms that clearly govern the integration. If the API is important to your product or customer service, negotiated terms are often worth considering before you sign.

Who owns the data sent through an API?

That depends on the contract. A well drafted API agreement should distinguish between your business data, customer personal information, provider materials, API output, and aggregated usage data, rather than treating all data the same way.

What should I negotiate first in an API contract?

Start with the clauses that affect commercial risk most directly:

• permitted use and sublicensing
• data rights and privacy
• service levels and change notice
• fees and pricing changes
• liability caps and indemnities
• suspension, termination and exit support

Can an API provider change terms after I sign?

Sometimes, yes, if the agreement gives them a unilateral variation right. That clause should be reviewed carefully, including as part of a contract review. For important integrations, you may want notice periods, limits on material changes, or a right to terminate if the changes are commercially unacceptable.

Key Takeaways

• An API agreement is a commercial contract that can shape your product risk, customer promises and operating costs.
• The most important clauses usually cover licence scope, data ownership, privacy, security, service levels, fees, liability and termination.
• New Zealand businesses should check whether personal information is involved and make sure privacy disclosures and contractual obligations line up.
• Standard online API terms often favour the provider, especially on suspension rights, warranty exclusions and low liability caps.
• Your upstream API contract should be consistent with your downstream customer terms, particularly where you promise uptime, data handling standards or support levels.
• Key promises made in sales discussions should be written into the contract before you accept the provider's standard terms.

If you want help with data rights, privacy obligations, liability terms, or termination rights, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.