API
An application programming interface (API) is the defined contract by which one piece of software requests data or actions from another — the endpoints, the requests and responses, the authentication, the errors — so that systems built by different teams and companies can work together without sharing their internals. Fintech runs on APIs: a payment is an API call, a bank account is read through one, and a fintech's own product is often an API its customers integrate.
- Also known as
- Application programming interface, APIs, REST API, API integration
- Used at
- every integration between systems — payments (Stripe, Adyen, the acquirers), banking (open banking, BaaS), identity and compliance vendors, card issuing, data providers, accounting and ERP connections, and the internal services of any modern platform; also the product itself for API-first companies
- Binding
- no rule on APIs in general; specific regimes require them (PSD2's open-banking access, with the EBA's standards and the Berlin Group and UK Open Banking specifications), security standards govern their protection (PCI DSS for card data, OAuth 2.0 and mutual TLS as practice), and DORA in the EU treats API dependencies as ICT risk
- Typical design
- REST over HTTPS with JSON, resources addressed by URLs and manipulated with standard verbs; authentication by API keys or OAuth tokens; versioning so that changes do not break integrators; idempotency keys so that retries do not duplicate payments; webhooks for events the caller did not poll for; rate limits; documentation with examples; sandboxes for testing; and a status page for incidents
- Typical quality signals
- consistency, predictability, clear errors, backward compatibility, latency at the 99th percentile, uptime, and the time a new integrator takes to a first successful call — the measure API-first companies optimise
- Parties
- the provider, the integrators (customers and partners), the developers on both sides, the security teams that review every connection, and the buyers who diligence the integrations
How an API works in practice
A merchant's checkout sends a request to a payment provider's API: POST /payments with the amount, currency, a token for the card, and an idempotency key. The provider authenticates the request with the merchant's key, validates it, routes the authorisation to the acquirer and the scheme, and responds within a second with a payment object — its ID, status and any next action (a 3-D Secure challenge to present). Later the provider posts a webhook to the merchant's endpoint when the payment is captured, refunded or disputed. Every step is defined in the API's contract, every field documented, every error coded; the merchant's engineers integrated it in days from the documentation and the sandbox, and the provider can change its internals freely as long as the contract holds. The same shape serves a fintech reading a customer's bank account through open banking, calling an identity vendor, or issuing a card.
For a fintech whose product is an API, the contract is the product: its design decides how fast customers integrate, how rarely they call support, and how hard they find it to leave. Versioning discipline keeps thousands of integrations working across years of change; a breaking change is an incident. Idempotency and clear failure semantics are the difference between a duplicate payment and a safe retry. Security — key management, scoped tokens, encryption, logging — is a regulatory matter when the data is financial. And the dependencies run both ways: a fintech depends on the APIs of its acquirers, banks and vendors, and their outages and changes become its own. In diligence, a buyer reads the target's API documentation, its version history, its uptime record and the number of live integrations, because the integrations are what customers would have to rebuild to switch.
For a fintech, an API is the contract with every customer and partner, and its quality is a commercial asset measured in integration time and churn; for a buyer, the live integrations are the switching cost the price is paying for.
Example
A payments company's API has 4,000 live merchant integrations, a documented version history with no breaking changes in five years, idempotency on every write, 99.99% measured uptime, and a median time to first successful sandbox call of 40 minutes. A competitor with similar volume has 1,200 integrations, three breaking versions in five years and a median first call of two days. A buyer values the first at a 40% premium per unit of revenue: its integrations churn at 3% a year against the competitor's 11%, and its support cost per merchant is a third. Diligence confirms it by reading the changelog, sampling the documentation, running the sandbox, and interviewing ten merchants, three of whom say they chose the provider for the API and would not leave for a lower price.
Common mistakes
- Breaking changes without versioning, which turn every release into customers' incidents. - Writes without idempotency keys, which turn retries into duplicate payments. - Documentation that lags the API, so integrators learn from errors. - Keys and tokens managed carelessly; an API to money is a target. - Valuing an API-first company on volume without counting the live integrations and their churn.