API Endpoints
An API endpoint is a specific address — a URL and a method — at which a piece of software accepts requests or delivers responses through an application programming interface: POST /payments creates a payment, GET /accounts/{id}/transactions lists transactions. An API is the set of its endpoints and the contract each follows; the design of the endpoints — what each does, what it requires, how it fails, whether it is safe to retry — decides how easily customers integrate.
- Also known as
- Endpoints, REST endpoints, API routes, Endpoint design
- Used at
- every payment, banking, identity and data integration; a payment provider's API may expose a few dozen endpoints (payments, refunds, customers, tokens, disputes, payouts, reports, webhooks), a bank's open-banking API the standardised endpoints the regulation specifies (accounts, balances, transactions, payment initiation, consents)
- Binding
- for open banking, the technical standards (the EBA's RTS, the Berlin Group and UK Open Banking specifications) define endpoint behaviour, performance and availability; PCI DSS governs endpoints that touch card data; DORA and outsourcing rules treat critical API dependencies as ICT risk; security frameworks (OWASP API Security Top 10) are the practical standard
- Typical design
- resource-oriented URLs, standard methods (GET reads, POST creates, PUT/PATCH updates, DELETE removes), JSON bodies, consistent error codes with machine-readable reasons, pagination on lists, idempotency keys on every endpoint that creates or moves value, rate limits, authentication on every call (API keys, OAuth 2.0 tokens with scopes, mutual TLS), input validation, and versioning in the path or headers
- Typical failures
- endpoints that create duplicate payments on retry (no idempotency), broken object-level authorisation (one customer can read another's resource by changing an ID — the most common API vulnerability), excessive data exposure (an endpoint returns fields the caller should not see), missing rate limits, undocumented behaviour, and breaking changes shipped without a version
- Parties
- the API's designers and engineers, the integrators, the security team that tests each endpoint, the compliance team for the data each returns, and the monitoring that watches latency, errors and abuse per endpoint
How API endpoints work in practice
A payment provider designs its payments endpoint. POST /v2/payments accepts amount, currency, a payment-method token, a customer reference and an idempotency key in the header; it authenticates the caller's key, checks the key's scope permits creating payments, validates every field, creates the payment, routes the authorisation, and returns a payment object with an ID, a status and any next action, within a second at the 99th percentile. A retry with the same idempotency key returns the same payment, not a second one. GET /v2/payments/{id} returns the payment — only if it belongs to the caller's account, which the endpoint checks on every request. POST /v2/payments/{id}/refunds creates a refund, again idempotent, again scoped. Every endpoint is documented with examples and error cases, monitored for latency and error rate, rate-limited per key, and versioned so that /v2 keeps working when /v3 ships.
The security of a fintech's API is the sum of its endpoints' controls, and the audits look at each. Object-level authorisation is checked on every endpoint that takes an ID. Endpoints that return customer data return only the fields the scope allows. Endpoints that move money require idempotency, authentication and limits, and are logged completely. Webhook endpoints — the ones the fintech exposes to receive events — verify signatures so that a forged event cannot mark a payment as paid. Open-banking endpoints must meet the regulation's availability and performance standards, which banks report on. For a fintech, the endpoint inventory, its documentation and its test coverage are the shape of the product; for a buyer, a penetration test of the endpoints and a read of the API's changelog are the technology diligence's first week.
Example
A payments fintech's penetration test before a Series B finds: GET /v1/customers/{id} returns any customer's record to any authenticated key (broken object-level authorisation); POST /v1/payouts has no idempotency key, and a network retry in the previous month had caused 40 duplicate payouts totalling €180,000, recovered from merchants over two weeks; the webhook receiver accepts unsigned events; and three internal endpoints are exposed without authentication. Fixes take six weeks: ownership checks on every ID-taking endpoint, idempotency on every write, signature verification on webhooks, the internal endpoints moved behind the network boundary, and per-endpoint monitoring with alerts on error-rate and volume anomalies. The investor's technical diligence re-tests and clears the round; the duplicate-payout incident becomes the company's case study for why every value-moving endpoint is idempotent.
Common mistakes
- Endpoints that take an ID and do not check the caller owns the resource. - Writes without idempotency keys. - Returning whole objects when the caller needs three fields. - Webhook receivers that trust unsigned events. - Shipping a breaking change to an endpoint without a new version.