IP Licence Agreement Checklist For SaaS Integrations

Licensing your SaaS product into another platform can be a huge growth opportunity. Maybe another company wants to connect to your API, embed part of your software, use your data feed or offer your tool to its own customers.

That kind of integration can be valuable, but it also opens up a few big questions. Who can access what? Can they pass it on to their customers? What happens if they exceed the usage limits? Who owns improvements or integration code?

An IP licence agreement in NZ helps you answer those questions clearly before the integration goes live. The aim isn't to make the deal feel heavy. It's to protect the product you've built, set commercial expectations and make the relationship easier to manage as it grows.

What Is An IP Licence Agreement For A SaaS Integration?

An IP licence agreement is a contract that lets another business use your intellectual property for specific purposes, without giving them ownership of it.

For a SaaS integration, the licensed IP might include:

• Your software, code, platform features or hosted functionality
• Your API, API keys, SDKs, developer tools and documentation
• Your database structure, data feeds, analytics or reports
• Your brand assets, trade marks, logos or product names
• Your confidential technical information, security processes or integration specifications

This is different from selling your IP. In most SaaS integration deals, you want the other business to use your technology in a controlled way while you keep ownership of the product, roadmap, codebase and brand.

In New Zealand, copyright can protect original software code and documentation under the Copyright Act 1994. Trade marks can be registered through IPONZ under the Trade Marks Act 2002. Even where your IP is protected automatically, your contract still does a lot of practical work. It tells the customer exactly what they're allowed to do and what they're not allowed to do.

For example, a licence might let a payroll platform call your API to display your compliance alerts to its users. It might not let that platform copy your database, train a competing tool, reverse engineer your software or sell access to unrelated third parties.

Do You Need A Software Licence Agreement In NZ?

Yes. If another business is using your software, data or API beyond ordinary end-user access, you should usually have a written software licence agreement, SaaS integration agreement, API agreement or data licence agreement.

Your standard SaaS terms might be enough for a simple customer account. But once you're dealing with an integration, the commercial and technical risks are usually different. The other business may be connecting systems, handling shared data, building features on top of your API or making your product available to its own customers.

A tailored agreement becomes especially useful where:

• The customer gets API access or developer credentials
• Your tool is embedded, white-labelled or co-branded under a white label SaaS arrangement
• The other business can make your functionality available to its customers as a reseller
• Fees depend on usage, seats, transactions or data volumes
• The integration involves personal information under the Privacy Act 2020
• You need audit rights, security requirements or usage reports

New Zealand business-to-business contracts also need to be drafted carefully around consumer and fair trading laws. The Fair Trading Act 1986 can apply to misleading claims about your software, uptime, data or performance. It also regulates unfair contract terms in standard form small trade contracts where the annual value of the trading relationship is $250,000 or less when the relationship starts.

If you're supplying services for business purposes, you may be able to contract out of parts of the Consumer Guarantees Act 1993, but only where it's fair and reasonable. Your agreement should handle this clearly rather than leaving it to guesswork.

What Should Your SaaS Integration Agreement Cover?

Your SaaS integration agreement should spell out the licence scope, commercial model, technical rules, data obligations and exit process.

A template can be a useful starting point, but SaaS integrations tend to turn on the details. A generic document may not cover API limits, sub-customers, logs, overage fees, security incidents or what happens when access is switched off. Your legal adviser should tailor the agreement before you use it.

Here is a practical fill-in outline you can use to plan the document:

1. Parties and background: Write who owns the product, who is receiving access and what the integration is meant to achieve.
2. Definitions: Define the platform, API, data, documentation, end users, usage limits and integration environment.
3. Licence grant: State exactly what the customer can use, for what purpose, in which territory and for how long.
4. Restrictions: Ban copying, reverse engineering, scraping, benchmarking, competing use, unauthorised sharing and misuse of credentials.
5. Sublicensing and end users: Say whether the customer can give access to its own customers, affiliates, contractors or resellers.
6. Fees and reporting: Set the pricing model, usage reports, invoicing timing, overage fees and what happens if numbers are under-reported.
7. API access and service levels: Cover keys, authentication, rate limits, uptime targets, maintenance windows and support responsibilities.
8. Data and privacy: Allocate responsibility for personal information, security, breach notifications, data retention and permitted data use.
9. IP ownership: Confirm who owns existing IP, integration code, improvements, feedback, trade marks and documentation.
10. Audit rights: Give you a practical way to check usage, fees, sublicensing and compliance with technical limits.
11. Termination and exit: Set out termination rights, transition periods, data deletion, final invoices and what access stops immediately.

The right balance depends on the integration. A low-risk internal API feed may only need a light agreement. A white-labelled product used by thousands of end users needs much tighter controls.

How Should You Set API Access, Usage Limits And Sublicensing?

You should set API access, usage limits and sublicensing rights as specifically as possible, because vague wording is where many SaaS disputes start.

Access Model

Start by deciding how the other business will access your technology. For example, will they receive sandbox access first? Will production access need your written approval? Can they create multiple API keys? Who inside their organisation can use them?

Your agreement should also say that credentials are confidential and can't be shared outside the approved integration team. If an API key is compromised, you should be able to suspend or rotate it quickly.

Usage Limits

Usage limits should match how your product actually costs you money. You might cap:

• API calls per month
• Number of end users, seats or customer accounts
• Data storage, data exports or report generation
• Transactions, records processed or requests per minute
• Geographic markets or business units using the integration

Say Mia runs an Auckland analytics SaaS. She licenses API access to a payroll platform for NZ$1,200 per month, including 100,000 API calls. The agreement says extra calls cost NZ$0.015 each and the customer must provide a monthly usage report.

In month three, the payroll platform makes 300,000 calls. Because the agreement has clear usage terms, Mia can invoice an extra NZ$3,000 for the 200,000 extra calls. Without that clause, she might be stuck arguing about whether the extra usage was included.

Sublicensing

Sublicensing means the customer can pass some access rights to someone else. In SaaS integrations, that might include the customer's own customers, affiliates, implementation partners or contractors.

Don't leave sublicensing open-ended. If you allow it, say who can receive access, what they can do, whether they need to accept end user licence terms, and whether the customer remains responsible for their conduct.

Who Owns The IP, Data And Improvements?

You should own your pre-existing software, API, documentation, trade marks and product IP unless you intentionally agree otherwise.

Your agreement should draw a clear line between background IP and anything created during the integration. This matters because integration work often creates a mix of technical outputs, including connectors, mapping rules, custom workflows, data schemas, dashboards, documentation and feedback.

A practical ownership clause might cover:

• Your background IP: Your existing platform, source code, object code, APIs, algorithms, documentation and brand stay yours.
• The customer's background IP: Their systems, data, brand assets and internal documentation stay theirs.
• Integration materials: Decide who owns connectors, middleware, scripts, configuration files and implementation documents.
• Improvements: Say whether improvements to your product belong to you, even if they arise from customer feedback.
• Feedback: Give yourself the right to use suggestions without owing extra fees, unless you've agreed to a paid software development model.
• Trade marks: If either side can use the other's logo, set approval rights, brand guidelines and when use must stop.

Data needs its own treatment. People often say data ownership, but in practice you're usually agreeing who can access data, use it, disclose it, retain it and delete it.

If the integration involves personal information, the Privacy Act 2020 needs attention. You should decide which party is collecting personal information, what each party can use it for, how security incidents are handled and whether information is disclosed overseas. New Zealand's privacy rules include requirements around notifiable privacy breaches where serious harm is likely and restrictions on cross-border disclosure.

If you want to use aggregated or de-identified data for analytics, benchmarking or product improvement, say so clearly. Don't rely on silence, especially where customer trust and privacy are central to the deal.

What Happens If The Integration Stops Working Or The Agreement Ends?

Your agreement should explain what happens during outages, suspension and termination, because switching off an integration can affect both businesses quickly.

For day-to-day performance, be realistic about what you're promising. If your marketing says access is real time or unlimited, your contract should either support that promise or qualify it carefully. Misleading claims can create risk under the Fair Trading Act 1986.

Your agreement can deal with service issues by covering:

• Planned maintenance windows and how much notice you'll give
• Support channels, response targets and escalation steps
• Whether service credits apply, and whether they're the customer's sole remedy for downtime
• Your right to suspend access for security risks, misuse, non-payment or excessive load
• Customer responsibilities, such as secure coding, authentication and not overloading the API

Termination rights should be clear and workable. You might allow termination for unpaid invoices, serious breach, repeated overuse, unauthorised sublicensing, security incidents, insolvency or the customer using your IP to build a competing product. Some breaches can have a cure period, such as 10 business days to fix non-payment, while urgent security issues may justify immediate suspension.

The exit process is just as important as the right to terminate. Your agreement should say when API keys are revoked, whether there's a transition period, how final usage fees are calculated and what happens to shared data.

For example, you might give the customer 30 days to export approved data after ordinary termination, but require immediate deletion of cached data, API credentials and confidential documentation. If end users rely on the integration, a short wind-down period can protect your reputation while still giving you control.

Common Mistakes To Avoid

Most SaaS integration problems come from leaving commercial assumptions unstated. A few extra clauses at the start can save a lot of awkward conversations later.

Watch out for these common mistakes:

• Using ordinary SaaS terms for a deeper integration: Standard customer terms often don't cover API keys, end users, sublicensing, usage logs or audit rights.
• Letting usage grow without a pricing trigger: If the customer adds more users or calls than expected, you need a clear way to charge for that extra load.
• Allowing vague reseller rights: Words like partners, customers or affiliates can be too broad unless you define who they're and what they can do.
• Forgetting audit rights: If fees depend on usage or sublicensing, you need access to reports, logs or records to verify the numbers.
• Ignoring open source components: If your integration uses open source software, check the licence terms so you don't accidentally create obligations to disclose code or pass terms downstream.
• Overpromising on uptime or data accuracy: Sales statements, website claims and contract wording should line up. If they don't, you may face commercial pressure or Fair Trading Act risk.
• Leaving privacy until the end: If personal information moves through the integration, build Privacy Act 2020 obligations into the contract, not just the technical build.
• Not dealing with improvements: Customer feedback can be valuable. Make sure you can use it to improve your product without creating ownership arguments later.

The best agreement is usually the one your product team, sales team and leadership can actually follow. If the contract says one thing and the integration is built another way, you'll still have problems.

Key Takeaways

• An IP licence agreement for a SaaS integration should let the other business use your technology without transferring ownership.
• Your licence should be specific about API access, usage limits, sublicensing, fees, audit rights and termination.
• NZ laws such as the Copyright Act 1994, Trade Marks Act 2002, Privacy Act 2020, Fair Trading Act 1986 and Consumer Guarantees Act 1993 can all be relevant.
• Data clauses should cover permitted use, privacy responsibilities, breach handling, retention, deletion and any overseas disclosure.
• A checklist or template can help you plan the deal, but the final agreement should be tailored to your integration and pricing model.

If you'd like help with your IP licence agreement, SaaS integration terms, API usage rules or privacy and data clauses, you can reach us at 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligation chat.