API engineering is the discipline of designing the contracts other software lives on: the endpoints, schemas, gateways and SDKs that decide whether integration is a day of work or a quarter of tickets. The field is central and getting stranger. Postman's 2025 State of the API report, from more than 5,700 developers, finds 83.2% of organisations practising some level of API-first development, REST still dominant at 93% adoption, and 24.3% of developers now designing APIs with AI agents in mind. The security side is heating at the same pace: Kong's survey of 700 IT leaders records 55% experiencing an API security incident in the past year, with 47% of those spending more than $100,000 on remediation. API engineering hiring sits exactly at that intersection: contracts are worth more, consumers are multiplying, and the failure modes have never been more expensive.
Challenges in API Engineering Recruiting
REST API design that survived version one
Version one is easy; the discipline starts at version two. The survey shows REST remains the default at 93% adoption, which means the field's hiring problem is depth inside a paradigm everyone claims, and the fastest mover in the framework layer points where the work is going: FastAPI gained 5 points year over year, the largest single shift among web frameworks. REST API design done seriously is versioning strategy: additive change, deprecation windows, the error contract clients can branch on, pagination that survives ten million rows. Done casually it is a URL and a JSON blob. The interview probe is a live versioning exercise: walk a resource to v2, name what breaks for existing clients, how deprecation is signalled, what the contract says when the caller sends an unknown field. Candidates who have carried a public API through a version change answer in client terms: who they notified, what the adoption curve was, which mistake they had to live with. Candidates who have only written endpoints answer in shape.
GraphQL and gRPC split the same job title
The paradigm split is the field's sharpest internal boundary. The survey records GraphQL at 33% adoption alongside webhooks at 50% and WebSockets at 35%, while gRPC owns the internal service mesh where typed contracts and streams matter more than browser reach. The three demand different instincts. GraphQL is schema federation, resolver performance and query-cost control, the art of letting clients ask while preventing them from bankrupting the database. gRPC is typed IDLs, deadlines, streaming semantics and code generation, the art of the internal contract. REST is the art of the public one. A candidate who has run all three is rare, and a brief that lists all three is usually hiring by buzzword inventory rather than by the consumer the API serves. Name the consumer: browser clients, mobile clients, other teams' services, external integrators. The paradigm follows, and so does the shortlist.
API gateways concentrate every failure mode
The gateway is where every API decision becomes an operational one, and the operational record shows the strain. The survey finds 31% of organisations running multiple API gateways, which is governance fragmentation by another name. Kong's security data adds the risk surface: AI-enhanced attacks are the top ranked threat, 92% of organisations are taking measures, and shadow APIs, endpoints nobody has catalogued, are the blind spot the majority of organisations carry. Gateway hiring therefore means incident depth with routing attached: the rate-limit policy that throttled the wrong tenant, the plugin upgrade that broke routing, the auth chain that let a service call skip the identity layer. The screening question is about blast radius: what did the gateway see when a downstream degraded, and what did it hide. Candidates who have run a gateway answer with traffic shapes; candidates who have configured one answer with feature lists.
SDK development is product work under a semver contract
SDK development looks like a wrapper and behaves like a product. An SDK carries its own semantic version, its own release cadence, its own breaking-change policy, multiplied across languages and package managers, with documentation as the actual developer interface. The survey quantifies why this is hard: 93% of API teams report collaboration blockers, documentation gaps at 55%, duplicate efforts at 35%. The hiring consequence is that SDK engineers need product judgment inside engineering discipline: what the regeneration pipeline emits when the API drifts, who answers the integrator's issue, how a breaking change gets staged so nobody's build breaks overnight. Ask candidates what their SDK promised and failed to keep, which language binding taught them the most, and why hand-written beats generated for one case but not another. People who treat SDK development as thin wrapping are how developer interfaces rot, and the rot is invisible until the integrators leave.
Integration engineering where the customer is another engineer
The newest growth in API work is integration engineering aimed at non-human consumers. Nearly a quarter of developers, 24.3%, now design APIs with AI agents in mind, and awareness of the Model Context Protocol has spread fast, with two-thirds of developers aware of it within a year of launch, though only 10% use it regularly. Integration engineering for agents is different from integration engineering for people: the consumer retries differently, lacks intuition about intent, and will happily call the destructive endpoint because the description implied it. That raises the security bar the entire discipline has been climbing toward: OWASP's Top 10 keeps broken access control at number one, with an accessible API missing access checks on POST, PUT and DELETE among its canonical examples. Candidates for this seat need the security instinct and the design instinct together: what would an agent misunderstand about this contract, what must be denied by default, what should the error response teach. Most API careers have one half; the agent era pays for both.
Breaking changes expose inflated REST API design claims
API CVs compress easily because the nouns are standard: REST API design, GraphQL, gRPC, API gateways, SDK development. Verification has to follow the contract's history, which is the discipline's honest audit trail. Pick an API the candidate owned: who consumed it, what the versioning policy was, what breaking change slipped through and what it cost, how deprecation was announced and enforced. The candidates who have owned a public contract answer with integrator names and adoption curves; the candidates who built endpoints answer with endpoint counts. The cost of a weak hire is public by definition: a breaking change shipped to paying integrators, a GraphQL query that took down the database, a contract nobody trusts enough to build on. Kong's remediation numbers put the price in writing: more than $100,000 for nearly half of incident victims, above $500,000 for one in five. API engineering assessment therefore has to be as careful as the contracts it is hiring for, because the consumers, human and otherwise, will be watching.
References
- 2025 State of the API Report — Postman. (accessed 2026-09-28)
- API Security Perspectives 2025: AI-Enhanced Threats and API Security — Kong. (accessed 2026-09-28)
- 2025 Stack Overflow Developer Survey: Technology — Stack Overflow. (accessed 2026-09-28)
- OWASP Top 10:2025 — A01 Broken Access Control — OWASP. (accessed 2026-09-28)
- One in Four Developers Now Design APIs for AI Agents, According to Postman's 2025 State of the API Report — Business Wire. (accessed 2026-09-28)