A payments startup has your SDK in its checkout. You ship a minor release on a Tuesday afternoon, and a change to how retries are handled means some of its customers get charged twice. Nothing in your own infrastructure went down. Your status page stays green the whole time. Two weeks later there's a letter from its solicitors. It wants the refund handling costs, the support overtime and the chargeback fees, and it says your liability cap doesn't apply because the loss came from a breach of your warranty.

Developer tools and API businesses have an unusual risk shape. You don't usually sell to end users. You sell a building block that other companies put inside their own products, so when something goes wrong it goes wrong inside someone else's business, and they lose money on their side. Most of the claims you're likely to face are contract claims from customers, not injury claims from the public, and the insurance that matters most is the policy that answers them.

This guide is for UK startups that sell to developers: API-first businesses (payments, identity, messaging, search, data, maps, AI inference), SDK and library vendors, developer platforms and hosted infrastructure, CI/CD, testing, observability and security tooling, low-code platforms, and open-core companies with a paid tier. It covers which insurance a devtools company needs, how SLAs and liability caps decide what a claim looks like, the wording points underwriters and buyers argue about, and what to have ready before you ask for cover.

Two boundaries first. If your question is about your own lost revenue when your platform or a cloud provider goes down, that's business interruption, covered on SaaS Business Interruption Insurance for UK Startups. This page doesn't repeat it. It deals with the other side of an outage: what your customers can claim from you. And if your product is a model whose outputs make or shape decisions, the model risk is on AI Insurance for UK Startups. The full startup cover map is on Startup Insurance UK.

Mesh'd Limited trading as Meshed is authorised and regulated by the Financial Conduct Authority under firm reference number 1033248. We arrange cover from the insurers on our panel and charge a flat 10% broker fee, with no admin add-ons. We don't publish prices: the premium for a devtools business depends on what your customers build on you, how much revenue runs through your API, and what you've signed. Named customer quotes are off.

The short version

Most UK developer tools and API startups need technology professional indemnity (tech PI, also called tech errors and omissions or tech E&O) and cyber, usually bought together and sometimes on one combined policy. Tech PI answers "your product failed or didn't do what you promised, and we lost money". Cyber answers "your systems were breached, or the data and credentials you hold were exposed". Add directors' and officers' (D&O) once you have investors or a board, employers' liability once you employ anyone (a legal requirement in Great Britain, minimum £5 million), and crime if a payment-diversion fraud against your own company would hurt. For most devtools companies, the most important document isn't a policy at all. It's the liability clause in your customer terms, because that clause sets the size of the claim your insurance will have to meet.

What kind of devtools business are you?

Underwriters don't price "developer tools". They price how your product can hurt a customer. These five profiles cover most of the market, and many companies are a blend.

The middle column matters most. An SDK that only renders a chart has a very different risk to an API that decides whether a payment goes through, even if both companies have similar revenue and headcount.

Where devtools claims actually come from

It helps to separate the ways a customer can lose money because of you. Each one ends up on a different part of a policy, or outside cover altogether.

1. Wrong answers. The API is up, but it returns incorrect data: a currency conversion using a stale rate, an address lookup pointing to the wrong property, a fraud score inverted by a bug. This is the core tech PI claim, a failure to perform the service with reasonable care and skill. In England, Wales and Northern Ireland, section 13 of the Supply of Goods and Services Act 1982 implies that term into a business contract for services; Scots law reaches a similar place through the common law.

2. Breaking changes. A deprecation you announced on your changelog but not by email, a field renamed in a minor version, a default changed in an SDK release. The customer's integration breaks. These claims tend to turn on your documentation and versioning policy as much as on your code.

3. Availability failures. You're down, or so degraded that you're effectively down, for longer than your SLA allows. Your customer's lost sales and the cost of their workarounds are a liability claim against you, and a tech PI matter. Your own lost revenue during the same outage is a business interruption question, and it lives on the SaaS business interruption page.

4. Security failures that travel. An attacker gets into your build pipeline and ships a malicious package version, or steals API keys from your logs, or uses your privileged access to reach customer environments. One incident becomes many incidents, one for each customer. The cyber policy (your own response costs and liability to others) and the tech PI policy (failure of your service) can both be engaged, which is why the boundary between them matters.

5. Intellectual property. Someone says your SDK copies their code, your API design infringes a patent, or your product ships an open-source component under licence terms you didn't follow. For most devtools startups this is a smaller risk than the first four. It matters more if you distribute code, and much more if you sell to US enterprises. More on this below.

SLAs: what you've actually promised

Most devtools startups publish an SLA because enterprise buyers won't sign without one. It's worth reading your own SLA the way a claimant's lawyer would.

Service credits are a remedy, not an insurance event. A typical SLA says that if monthly uptime falls below a set level, the customer gets a credit against future fees. Credits are a reduction in your revenue, not damages paid to a third party, and tech PI policies generally don't pay them. Treat credits as a cost of doing business and budget for them.

The sole-remedy sentence is the important one. The strongest SLAs say service credits are the customer's sole and exclusive remedy for availability failures. If that sentence is missing, or limited to "minor" breaches, the customer can claim credits and sue for damages. Underwriters ask about it, and enterprise buyers often try to delete it.

Watch what the SLA measures. Uptime alone is the easy promise. Latency, error-rate and support-response commitments are harder to keep, and each is another way to be in breach. "Correctness" commitments (that results will be accurate) are the most dangerous, because they turn a quality target into a warranty.

Make sure your contract defines "downtime". Scheduled maintenance, customer-caused errors, third-party outages (your cloud host, your upstream data vendor) and force majeure should all be carved out in writing. If your SLA doesn't exclude your cloud provider's outages, you've taken on their risk without their limitation of liability.

Liability caps: the clause that sizes every claim

Your customer terms almost certainly cap your liability, often at a multiple of fees paid in the last twelve months, and exclude indirect and consequential loss. Insurance and the cap work together. The cap sets the most a customer can usually recover; the policy limit needs to be at least that, plus defence costs, across every customer who might claim in the same policy year.

Four points come up again and again in devtools contracts.

Per claim or aggregate? In Drax Energy Solutions v Wipro [2023] EWHC 1342 (TCC), the High Court decided that a clause limiting "total liability" to 150% of the charges paid in the preceding 12 months set one aggregate cap across all of the customer's claims, not a separate cap for each claim. The customer had argued for separate caps that would have added up to about £132 million. The judge also said the clauses weren't well drafted. The lesson is to say clearly whether your cap is per claim, per year or for the life of the contract, and to match your policy limit to that.

Super-caps and uncapped carve-outs. Enterprise buyers routinely ask for a higher cap (a "super-cap") for data protection, confidentiality and security breaches, and for IP indemnities to sit outside the cap. Every carve-out you accept is liability your insurance has to absorb, or that you carry yourself. Before you sign, check that the cyber and tech PI limits you hold cover the super-cap.

What the law won't let you exclude. Under section 2(1) of the Unfair Contract Terms Act 1977 you can't exclude or restrict liability for death or personal injury caused by negligence. Other exclusions and caps in your written standard terms must pass the Act's reasonableness test (section 3). When a cap is a specified sum of money, section 11(4) tells the court to look at the resources you could expect to have to meet the liability and how far it was open to you to cover yourself by insurance. That's an unusual link between the law and your insurance programme: a cap set far below the cover you could reasonably have bought is easier to attack.

Time limits. Under the Limitation Act 1980, a customer in England and Wales usually has six years from breach to sue on a simple contract (section 5), and twelve years on a contract signed as a deed (section 8). Tech PI is written on a claims-made basis, so the policy in force when the claim is made responds, not the one in force when you shipped the bug. Keep cover continuous, keep your retroactive date, and if you're sold or wind down, ask about run-off cover.

Tech PI wording checks for an API or devtools company

Most tech PI policies are written for IT consultancies and software houses. A devtools company is closer to a utility, so some standard wording fits badly. These are the points to check, and to ask us about.

For the general product, see Professional Indemnity Insurance UK. The table above covers what's specific to developer tools.

Cyber for a company that holds other people's keys

A devtools company's own data is usually small. The risk is in what you hold or can reach for other people: API keys and OAuth tokens, webhook secrets, build artefacts, logs full of request payloads, and sometimes direct access to customer environments.

That changes how you should read a cyber policy:

• Third-party liability matters as much as first-party response. If your breach exposes customer credentials, the claims come from your customers, and from their customers through them. Check the liability section covers loss to third parties from transmission of malicious code and from your failure to secure data.

• Supply-chain incidents. A compromised dependency or a poisoned package published from your pipeline is a cyber event for you and a service failure for your customers. Ask how the policy handles a single incident with many affected customers.

• Data protection roles. If you process personal data on your customers' instructions you're usually a processor under UK GDPR. Article 82 says a processor is liable for damage only where it hasn't met the obligations aimed at processors, or acted outside the controller's lawful instructions. Your data processing agreement (Article 28) sets the instructions, so it shapes your exposure. If you use data for your own purposes, such as training, benchmarking or enrichment, you may be a controller for that use, and the exposure is bigger.

• Regulatory direction of travel. The Cyber Security and Resilience (Network and Information Systems) Bill would bring medium and large managed service providers that run or monitor customers' IT systems into the NIS Regulations, with registration, security and incident-reporting duties. Small and micro businesses are exempt. At 29 October 2026 the Bill had finished report stage in the Lords and wasn't yet law, and the detail would follow in secondary legislation. Most API and SDK vendors won't be "managed service providers" in the Bill's sense, but tooling that actively administers or monitors customer systems should keep an eye on it.

Cyber depth is on Cyber Insurance UK, and when to buy it is on When UK Startups Need Cyber Insurance. If you sell security products, the extra exposure is on Cybersecurity Company Insurance for UK Startups.

Intellectual property: when it's worth the conversation

IP cover is a specialist product, and many devtools startups don't need a standalone policy. It's worth discussing if:

• You distribute code. An SDK, a library or a self-hosted product is copied onto other people's systems. Computer programs are literary works under section 3 of the Copyright, Designs and Patents Act 1988, so a claim that your code copies someone else's is a copyright claim.

• Your customer contract has an IP indemnity. Most enterprise terms ask you to defend the customer if your product infringes a third party's rights, and often outside your cap. Some tech PI policies include IP infringement cover (sometimes excluding patents); others exclude it. Check which yours is before you sign the indemnity.

• Open-source licence compliance is part of what you sell. If you ship open-source components, an audit trail of licences and attribution notices is cheaper than any claim.

• You sell into the US. US customers, courts and patent claims change the risk and the jurisdiction wording you need. See US Expansion Insurance for UK Startups.

The full IP picture is on IP Insurance for UK Startups.

Selling into the EU: software becomes a "product"

The EU's new Product Liability Directive (2024/2853) says software counts as a product, whether it's installed, embedded or supplied as a service, and treats software developers as manufacturers. It applies to products placed on the EU market after the transposition deadline of 9 December 2026, and EU countries are still bringing it into national law. Three points for a UK devtools company:

• It's no-fault liability for damage to natural persons: death or injury, damage to property, and destruction or corruption of data not used for professional purposes. A B2B API is less exposed than a consumer app, but if your SDK ships inside consumer products sold in the EU, you can be in the chain.

• The Directive says the mere source code of software isn't a product, and free and open-source software developed or supplied outside a commercial activity is excluded. A paid tier or commercial distribution is commercial.

• Product liability is often excluded or limited on tech PI policies. If EU consumer exposure is real for you, tell us, so we can look at a products liability section alongside PI.

This is a short note, not legal advice on how each country is implementing the Directive.

The rest of the stack

• Directors' and officers' (D&O). Once you have investors, a board or a priced round, D&O protects directors personally. For devtools companies the trigger is usually the round, not the product. See Directors and Officers Insurance UK and the Series A Diligence Insurance Pack.

• Employers' liability. Compulsory in Great Britain once you employ staff, with a minimum of £5 million under the 1998 regulations. Remote-first doesn't change that. See Employers' Liability Insurance UK.

• Crime. If your finance team can be tricked into paying a fake invoice, or you hold customer funds through a payments API, crime cover is worth the conversation. See Crime and Fidelity Insurance for UK Startups.

• Public liability. Usually small for a devtools company, but often a line on enterprise questionnaires and needed for events and offices.

What enterprise buyers ask for

Devtools companies tend to meet insurance requirements in three places: the security questionnaire, the MSA's insurance clause, and marketplace listings. Typical asks are tech PI and cyber at limits the buyer names in the contract, certificates naming the policy period, and sometimes notice of cancellation. The two most common mistakes are agreeing an insurance clause that asks for cover you don't hold, and agreeing a super-cap above your policy limits.

• Questionnaire evidence: MSA Security Questionnaire Insurance Evidence for UK Startups and the SOC 2 / ISO Buyer Insurance Questionnaire Pack

• Selling through cloud marketplaces: AWS Marketplace Seller Insurance for UK Startups

Three scenarios

The retry bug. A payments SDK release double-charges a customer's users for six hours. The customer claims refund-handling costs, chargeback fees and staff time. Your terms cap liability at twelve months' fees and exclude indirect loss. Tech PI is the policy that responds: defence costs, then damages up to the cap if the claim succeeds. The fees the customer wants back are probably not covered. The lesson: release controls (canary releases, automatic rollback) are underwriting information, not only engineering hygiene.

The leaked keys. Debug logging in your hosted platform writes customer API keys to a log store, and a misconfigured bucket exposes it. Three customers see fraudulent usage on their accounts. Cyber pays for investigation, notification and key-rotation support, and the liability section responds to the customers' claims. Because every customer was hit by one cause, the policy's aggregation clause decides whether you pay one excess or three.

The enterprise rewrite. A bank wants to use your identity API. Its procurement team strikes your sole-remedy SLA sentence, asks for an uncapped data-protection indemnity and requires £10 million of cyber cover. Nothing has gone wrong yet, but this is where devtools insurance is won or lost. Before you sign, check what your current limits cover, what it would take to raise them, and whether a super-cap at a fixed multiple would satisfy the bank instead of unlimited liability.

What to have ready before you ask for cover

Underwriters for devtools businesses ask a consistent set of questions. Having these answers ready makes the conversation shorter and the quotes more accurate:

1. What your product does, in one paragraph, and the profile(s) from the table above.

2. Revenue for the last and next twelve months, split by UK, EU, US and rest of world.

3. Your largest customers, their sectors, and the share of revenue they represent.

4. Your standard terms: liability cap, exclusions, SLA, sole-remedy wording, IP indemnity.

5. Any signed contracts that depart from your standard terms, especially super-caps or uncapped carve-outs.

6. Uptime history over the last twelve months and your largest incident.

7. Release process: code review, testing, staged rollouts, rollback.

8. Security controls: MFA, secrets management, dependency scanning, SOC 2 or ISO 27001 status.

9. What customer data and credentials you hold, and whether you're a controller or processor for each.

10. Claims or complaints in the last five years, and anything you know of that could become one.

FAQs

Do I need tech E&O if my product is free?

If nobody pays, contract claims are less likely, but negligence claims are still possible, and free tiers often lead to paid enterprise contracts. Most devtools startups buy tech PI when they sign their first meaningful customer contract or when a customer asks for a certificate.

Will insurance pay our service credits?

Usually not. Service credits are a reduction in your fees, and tech PI policies generally exclude refunds of fees. Insurance is there for the damages claims that go beyond credits.

Does tech PI cover our own downtime losses?

No. Tech PI covers your liability to others. Your own lost revenue when you're down is business interruption, covered on SaaS Business Interruption Insurance for UK Startups.

Our cloud provider went down, not us. Can our customers still claim?

They can try, if your contract promised availability without carving out third-party outages. Your cloud provider's own terms will cap what you can recover from it. Make sure your SLA excludes upstream outages you don't control.

Should tech PI and cyber be on one policy?

Many devtools companies buy them together because the boundary between "service failure" and "security incident" is blurred. A combined policy, or both policies with the same insurer, reduces the risk of each policy pointing at the other. Combined limits can be shared, though, so check whether one incident could use up the cover for both.

What limit should we buy?

At least your largest contractual cap or super-cap plus defence costs, and enough to cover more than one customer claim in a year if one release can affect many customers. Contract requirements often set a floor.

We're a one-person API business. Can you help?

Yes, sole traders are in scope for tech PI and the other covers we place. We don't currently place cyber cover for sole traders, so if cyber is essential to you, we'll say so at the start.

We're open-core. Does the free community edition need cover?

Claims from community users are less likely and are often limited by the open-source licence's own disclaimers. The paid tier, support commitments and anything you warrant in an enterprise contract are where tech PI does its work. Tell underwriters about both.

Talk to us

If you run a developer tools or API startup and want your SLA, liability cap and insurance limits to line up, speak to us. Send your standard terms, any enterprise contracts that depart from them, and your current policies. We'll check the gaps and take your risk to the insurers on our panel. Meshed charges a flat 10% broker fee, and Mesh'd Limited trading as Meshed is authorised and regulated by the FCA under firm reference number 1033248.