“The API is slow” starts a hunt. Somebody opens the APM dashboard, somebody else greps the load balancer logs, a third person checks whether the database is on fire. An hour later the team has three theories and no measurement. One request, timed phase by phase, answers the first question in under a second: whether the time went to name lookup, the TCP connect, the TLS handshake, the server or the transfer of the body.

A team wants to delete GET /v1/invoices/{id}/legacy-pdf. A search across the main repo finds no caller, and the gateway logs show zero hits in the last 30 days. The route goes out in a cleanup PR. On the first business day of the next quarter, a partner’s reconciliation job starts failing: it calls that endpoint four times a year, and nobody on the team knew the partner was still there.

You inherit an integration with a partner API that has 140 endpoints, documented in alphabetical order. GET /accounts sits next to GET /adjustments, and POST /refunds is a long scroll away from the GET /charges/{id} it depends on. Nobody wrote down that a refund hangs off a charge, which hangs off an order, which may or may not have a customer. You find out the slow way: call an endpoint, copy an ID out of the response, paste it into the next call, and keep a diagram in a notebook that’s out of date by Thursday.

A customer’s checkout returns a 500. Support pastes the request ID into the ticket, and the engineer on call finds the log line: KeyError: 'tax_region' in the pricing module. They send the same request locally and get a 200. Of course they do. Their database has no customer with a null tax region, the feature flag that routes to the new tax engine is off in development, the rates service answers differently today, and the clock is a day later. The bug is a function of all of that, and the ticket contains none of it.

You’re about to refactor the billing endpoints. The service has a few dozen tests, mostly happy paths, and nobody trusts them to catch a changed rounding rule or a renamed field. Writing better ones by hand means reading every handler and inventing inputs. Meanwhile production receives thousands of real inputs a minute, and each one comes labelled with the response your current code gives.

Capturing that traffic is the easy part; a proxy, a packet tap or a log line with the body in it will do. The product is everything after. Ten minutes of traffic holds thousands of near-duplicate requests and a handful that exercise something different, and a tool is only useful if it can tell them apart. Cluster by endpoint, request shape and response shape. Pick representatives that cover the status codes and branches. Assert only on fields that are stable. Mock the downstream calls. What comes out is a few dozen characterization tests (Michael Feathers’ name for tests that pin down what code does today).

Stripe charges per transaction. Twilio charges per message and per minute. OpenAI charges per token. Three companies, three completely different units of value, three pricing models built around what actually costs them money or reflects what the customer gets. Picking a monetization model for an API isn’t a marketing decision bolted on at the end — it shapes how the API gets designed in the first place.

Pay-per-call

The simplest model: charge a flat fee for every request, sometimes with volume discounts at higher tiers. Google Maps and most geocoding APIs work this way. It’s easy for a customer to understand and easy for a provider to bill, since usage tracking is just a request counter.

An API can pass every unit test in its suite and still break every client that calls it, because unit tests check that functions do what the code says they do, not that the API does what the contract says it does. That gap is where most production API incidents actually come from: a field renamed, a status code changed from 200 to 204, a required parameter quietly made optional. Testing an API well means testing at several different levels, because each one catches a different class of failure.

Ask two developers in 2026 what platform they use to design an API, and you will get two answers that have almost nothing in common. One of them means the tool where they write the OpenAPI document, lint it, mock it and publish the reference docs. The other means the layer that sits between their application and a dozen model providers, routing requests to whichever LLM is cheapest or still up. Both groups call it “API design.” Both groups are right, because the two stacks have quietly grown into each other.

Orkes, the workflow and agent orchestration platform founded by the original engineers behind Netflix’s microservices infrastructure, has closed a $60 million Series B round led by AVP, with participation from Prosperity7 Ventures, Nexus Venture Partners, Battery Ventures, and Vertex Ventures US. The raise signals growing enterprise demand for orchestration infrastructure that can take AI workloads from prototype to production without falling apart.

The company’s foundation is Conductor, an open-source orchestration engine originated at Netflix in 2016 and still actively maintained by Orkes. Netflix’s own internal usage of Conductor has grown fivefold in recent months, and the project counts developers at JP Morgan Chase, Tesla, Atlassian, Oracle, American Express, and GE Healthcare among its users. Since its $20 million Series A in 2024, Orkes has tripled its paying customer base and built a developer community in the hundreds of thousands.