API as a Product

Who a commercial API is for

An API becomes a product when someone outside pays for it, or when it decides whether customers choose your platform. Typical buyers of this service are:

• companies holding unique data (pricing, logistics, catalogue, registry) that they currently sell as files or reports;
• SaaS vendors whose customers want integration with their own systems and will pay for it in a higher plan;
• businesses with a distinctive capability, such as a calculation, a verification or document generation, that others want to embed in their products;
• organisations sharing data with partners under defined terms that must control who takes how much.

The difference from an ordinary integration is fundamental. The consumer is a stranger company that does not know your systems, signs up on its own in the middle of the night and expects the interface not to change without notice. If you only need to connect your own systems, API development and integration is the better fit.

Business model first, code second

Before the first endpoint exists, we settle the questions that determine the architecture:

• Billing unit: call, record, document, active object or flat subscription; whether failed calls are billable.
• Plans: free trial access, plans with a monthly quota, custom contracts for large consumers.
• Data rights: whether you may resell the data you process and under which licence terms. This is worth confirming with a lawyer.
• Commitments to customers: what availability and support response you want to offer, and what transition period breaking changes will get.
• Sales channel: self-service sign-up with a card or sales-led contracts with invoicing.

The answers go into the specification, because a "pay per record" model needs entirely different metering from a "10,000 calls per month" bundle.

Modules of a commercial API

Organisations, users and keys

A customer creates an organisation account, invites teammates and issues scoped keys, separate for sandbox and production. Keys can be rotated and revoked without contacting your support. For server-to-server integrations, OAuth 2.0 client credentials are available as well.

Quotas, plans and usage metering

Every call is attributed to a key and an organisation. Rate limits protect the infrastructure; plan quotas protect your revenue model. Usage is aggregated and passed to billing (for example Stripe Billing or your own invoicing system), and customers see it in their dashboard before the invoice arrives.

Developer portal

Interactive documentation generated from OpenAPI, a quick-start guide, examples in several languages, a sandbox with test data, a changelog and a status page. This is often the strongest sales asset: a customer's developer forms an opinion of the product within the first hour with the docs.

Webhooks and bulk access

Some customers need change notifications, others a periodic export of the full dataset. Both channels follow the same authentication, quota and billing rules as the API.

Admin console

Your team sees customers, plans, usage, errors and suspicious traffic patterns, and can change a plan, grant an exception or block a key.

Architecture: off-the-shelf gateway or your own layer

The commercial layer can sit on an existing API gateway (Kong, Tyk, AWS API Gateway, Azure API Management and similar) or be built as a lightweight service in front of your API. A managed gateway gives you keys and limits immediately but ties you to a vendor and its pricing; your own layer gives full control over metering and billing. We make a recommendation after looking at volume, billing model and your team's skills.

Whichever route you take, the product core (your data or logic) is separated from the access layer, customer data is isolated, and metering runs asynchronously so it never slows responses. The portal is usually a web application (Next.js, for instance) driven by the same OpenAPI contract as the API. If the platform is being built from scratch, it is worth treating it as a SaaS MVP in which the API is one channel.

Security, abuse and compliance

• keys stored only as cryptographic hashes, with a recognisable prefix that helps secret scanners detect leaks, and instant revocation;
• data isolation between organisations verified by automated tests on every release;
• protection against scraping and free-tier abuse: limits, sign-up verification, detection of unusual traffic;
• backward compatibility confirmed by contract tests before each deployment;
• GDPR: if the API processes personal data, controller and processor roles must be defined and data processing agreements put in place with API customers;
• review against the OWASP API Security Top 10, with particular attention to object-level authorisation and unrestricted resource consumption.

From idea to the first paying customers

1. Product discovery: interviews with prospective consumers or a review of past customer requests; choice of billing unit and plans.
2. Specification: API contract, account and permission model, quota rules, metering, version policy and portal scope.
3. Developer experience design: the path from sign-up to the first successful call, examples and error messages that make sense without contacting support.
4. Iterative build: keys, limits and documentation first, then billing, the self-service portal and the admin console.
5. Testing: customer isolation, quota overruns, key revocation, billing accuracy and load.
6. Closed beta: a few selected partners use the API before sign-up opens to everyone.
7. Launch and growth: monitoring, status page, release cadence and change communication.

The timeline depends mainly on whether the API core already exists, how complex the billing model is and how long legal decisions on data and terms take. A focused first stage is usually measured in weeks; a full self-service platform, in months.

Budget and scope options

The $1,900 anchor (excluding VAT) applies to a commercial layer on top of an existing, stable API: keys, limits, basic metering and documentation. A typical proposal has three options:

• Essential: keys and organisations, limits, documentation, manual plan assignment;
• Recommended: self-service portal, sandbox, metering integrated with billing, admin console;
• Scale: webhooks and bulk access, SDKs in several languages, advanced usage analytics, multiple regions.

The price also depends on whether the API core must be built or reworked, the number of plans and billing rules, availability requirements and how much the source data needs preparing. Gateway fees, payment-provider charges and cloud consumption are excluded. Licensing a ready-made core under your brand is covered on the white-label software page, and all price anchors are on the pricing page.

What to prepare before we talk

• a description of the data or functionality you want to sell, with confirmation of your rights to it;
• a list of prospective consumers and their typical use cases;
• initial ideas for plans and prices, even rough ones;
• access to the existing API or system that will form the product core;
• an owner for the terms of service, API customer support and change decisions.

With that material, get in touch. Other integration services are described under data and APIs, and delivering large datasets to customers on a schedule may also call for ETL connectors.

Related services

Frequently asked questions