API development company guide 2026: versioning, cost and security decisions

Summary. GitHub published REST API version 2026-03-10 on 12 March 2026, the first calendar version in its history to carry breaking changes, and committed to supporting the older 2022-11-28 version until 10 March 2028 before retired versions start returning 410 Gone. That 24-month window is the standard a buyer should hold an API development company to. The economics are just as concrete: Amazon API Gateway bills REST APIs at $3.50 per million requests against $1.00 per million for HTTP APIs on the first 300 million, plus $0.09 per GB of data transferred out. And the inventory problem is real. Cloudflare, analysing its own network traffic in January 2024, found 30.7% more API endpoints through machine-learning discovery than customers self-reported, which puts roughly a third of endpoints outside anyone's security review. OpenAPI 3.2.0, released 23 September 2025, and the OWASP API Security Top 10 2023 are the two documents most teams still have not read.

Most API projects do not fail on the code. They fail on the second year, when the first breaking change has to ship and nobody wrote down how clients would be told.

The three decisions that outlive the build

An API development company is worth hiring for judgement on three questions, not for endpoint throughput. Every one of them is cheap to decide on day one and expensive to revisit in year two.

The first is the versioning model. The second is the per-request cost profile, because that is set by the gateway and integration style you pick, not by how fast the handler runs. The third is how deprecation reaches a client that is not reading your changelog.

Versioning: four models, and what each one costs you

There is no single correct model. There is a correct model for a given consumer base.

Model	Client selects with	Real-world example	Support commitment	Main cost
URI path (/v1/, /v2/)	The URL itself	Widespread across public APIs	Whatever you publish	Every version is a separate route tree to operate
Date-based header	Request header	GitHub's X-GitHub-Api-Version, values like 2026-03-10	At least 24 months after a newer version ships	Server must branch on version for every changed field
Named release trains	Request header	Stripe's Stripe-Version, major releases such as Basil plus backward-compatible monthly releases	Account default version, upgradeable and reversible	Requires a changelog discipline most teams do not have
Content negotiation	Accept media type	Common in hypermedia designs	Whatever you publish	Poor tooling and cache behaviour
Additive-only, no versions	Nothing	Internal APIs with one consumer	None	Breaking changes become impossible, so the schema calcifies

GitHub's documentation is the clearest published statement of what a date-based commitment means. Breaking changes are enumerated: removing an operation, renaming a parameter or response field, adding a required parameter, making an optional parameter required, changing a type, removing enum values, adding a validation rule, or changing authentication requirements. Everything additive stays available in every supported version. Requests with no X-GitHub-Api-Version header default to 2022-11-28, and once a version passes its support window, unversioned requests fall through to the next oldest supported version rather than the retired one. That last detail is the one that breaks integrations quietly, and it is the kind of thing a buyer should ask about in the first design review.

Stripe takes the other path. Major releases carry names, monthly releases are backward-compatible only, and an account can roll its version back for 72 hours after an upgrade, with failed webhooks retried against the old object structure. That rollback window is a design decision with real operational value, and it exists because Stripe assumed upgrades would sometimes go wrong.

Pick one and write the policy down before the first endpoint ships. Retrofitting a versioning scheme onto a live API is the single most expensive remediation we see.

What the traffic actually costs

Gateway choice sets the bill, and the gap between the two Amazon API Gateway products is larger than most teams assume.

Amazon API Gateway line item	Price (US East, N. Virginia, August 2026)
HTTP API requests, first 300 million/month	$1.00 per million
HTTP API requests, above 300 million/month	$0.90 per million
REST API requests, first 333 million/month	$3.50 per million
REST API requests, next 667 million/month	$2.80 per million
REST API requests, above 1 billion/month	$2.38 per million
Data transfer out	$0.09 per GB
WebSocket connection minutes	$0.25 per million
API Gateway Portal, including 10 PortalProducts	$125 per month

AWS's own worked example makes the shape obvious: an API serving 432 million requests a month on HTTP APIs costs $418.80, an effective $0.97 per million. The same volume on REST APIs would sit in a tier charging $3.50 and $2.80 per million. At 15 billion calls a month with 4 KB responses, AWS's published REST example reaches $36,353.10 in request charges and $5,149.84 in data transfer, for $41,502.94 a month.

There is a second cost that never appears on the invoice. Cloudflare's traffic analysis found that by far the most common error response across APIs, at almost 52% of all 4xx and 5xx responses, was HTTP 429 — rate limiting. If half your error budget is spent telling clients to slow down, the throttling policy is a product decision, not an infrastructure setting.

Deprecation that clients actually receive

The standards for this exist and are boring, which is why so few teams use them.

Signal	Standard	What it carries
Deprecation header	RFC 9745, March 2025	A structured-field date, past or future, for when deprecation takes or took effect
Sunset header	RFC 8594, May 2019	The date the resource is expected to stop responding
Link with rel="deprecation"	RFC 9745, section 3	A URL to the migration guide and deprecation policy
application/problem+json	RFC 9457, July 2023	Machine-readable error detail, so clients do not parse prose
410 Gone	HTTP semantics	The terminal state after sunset, as GitHub uses for retired versions

Sanjay Dalal and Erik Wilde, the authors of RFC 9745 at the Internet Engineering Task Force, set the one hard constraint: "The timestamp given in the Sunset HTTP header field MUST NOT be earlier than the one given in the Deprecation header field." Their specification is equally clear that deprecation is a hint. "The act of deprecation does not change any behavior of the resource." A deprecated endpoint must keep working exactly as it did.

GitHub implements the pattern directly, emitting Deprecation and Sunset headers on responses while a version approaches retirement. That is the reference implementation to copy.

OpenAPI 3.2.0 matters here for a related reason. The release added first-class support for streaming media types including text/event-stream, application/jsonl, application/json-seq and multipart/mixed, each paired with the itemSchema keyword that describes a single streamed event. It also added the query HTTP method for idempotent queries with a request payload, an additionalOperations map for methods OpenAPI does not treat as first class, and OAuth 2.0 Device Authorization Flow. If your API streams anything, a 3.1 description cannot describe it accurately, and every generated client and every contract test inherits that gap.

The security floor

The OWASP API Security Top 10 2023 is the minimum review checklist, and its ordering is instructive. API1:2023, Broken Object Level Authorization, sits at the top because APIs expose endpoints that take object identifiers, and every function that reads a data source using a user-supplied ID needs its own authorization check. API3:2023 merges the old excessive-data-exposure and mass-assignment categories into Broken Object Property Level Authorization. API9:2023, Improper Inventory Management, is the one that connects back to Cloudflare's 30.7% discovery gap: you cannot secure endpoints you have not enumerated.

We treat three of these as gate conditions rather than findings. Object-level authorization is tested per endpoint, not per role. Every deployed environment has a generated inventory from the OpenAPI description, checked against observed traffic. And third-party API responses are validated on the way in, because API10:2023 exists precisely because developers trust upstream data more than user input.

What we build

eCorpIT builds and operates production APIs: public REST and GraphQL surfaces, partner integrations, internal service APIs behind a gateway, and the tool-facing APIs that AI agents call. The work usually falls into one of four shapes. A greenfield API platform with the versioning and deprecation policy written before the first endpoint. A modernisation, where an undocumented API gets an OpenAPI description, a contract-test suite and a migration path. A cost engagement, where the gateway and integration pattern are changed to move traffic off an expensive tier. Or an inventory and hardening pass against the OWASP list.

If you are choosing between protocols before you choose a partner, our comparison of REST, GraphQL and gRPC for agent tool APIs covers the trade-offs, and safe retries with idempotency keys covers the one correctness problem that bites every payments or booking API.

How an engagement runs

Five steps, in this order, on every API build we take on.

1. Discovery and contract. We write the OpenAPI 3.2 description first, including error shapes as application/problem+json, and agree the versioning model and support window in writing. Nothing is implemented until the contract is reviewed.
2. Reference implementation. One vertical slice through authentication, authorization, pagination, rate limiting and error handling, deployed to a real environment. This is where the object-level authorization pattern gets fixed.
3. Build against the contract. Contract tests run in CI from the same description that generates the client SDKs and the documentation, so the three cannot drift.
4. Load and cost modelling. We project request volume against the actual gateway tier before launch, because moving from a $3.50 per million tier to a $1.00 per million tier is a design change, not a config change.
5. Operate and deprecate. Inventory reconciliation against live traffic, Deprecation and Sunset headers wired into the release process, and a published migration guide behind a rel="deprecation" link.

The real cost is usually the migration, not the code.

The stack

Node.js and Bun, Python, Go and Java on the server side; our Bun versus Node.js runtime comparison sets out how we choose. Amazon API Gateway, Azure API Management, Kong and Cloudflare at the edge. OpenAPI 3.2 as the source of truth, with generated SDKs and contract tests. PostgreSQL and managed Postgres services for state. We are an AWS, Microsoft and Google partner, which matters mainly because it gets escalation paths when a managed gateway behaves unexpectedly at 3am.

India-specific considerations

For Indian deployments, two things change the design. Data residency and consent obligations under the Digital Personal Data Protection Act 2023 push personal data handling into explicit fields in the API contract, so that purpose and consent state travel with the request rather than living in a separate table nobody joins. We design applications aligned with DPDP Act requirements, and the cost of doing it after launch is a schema migration across every consumer.

The second is region pricing. AWS publishes the same $3.50 per million REST API rate for Asia Pacific (Mumbai) as for US East in its own worked examples, so the gateway tier decision does not change when you deploy in India, but data transfer and downstream service pricing do. Model the whole path, not the gateway line.

For teams whose problem is an existing integration estate rather than a new build, our API integration and modernization service is the closer fit, and the Interop 2026 web platform guide covers the browser-side constraints that shape public API design.

Why eCorpIT

We are eCorp Information Technologies Private Limited, founded in 2021 and based in Sector 83, Gurugram. We hold CMMI Level 5, ISO 27001:2022 and MSME certification, and we are partners with AWS, Microsoft, Google, Shopify and Kaspersky. Teams are senior-led and multi-disciplinary, which for API work means the person writing the contract is the person who will be on call for it.

Engagement models are a fixed-scope discovery and contract phase, a time-and-materials build, or a retained operate-and-evolve arrangement once the API is live. We will give you an indicative band for your scope on a call. We do not publish a rate card, because a per-endpoint price is a bad proxy for the work in any API that has to survive a version change.

FAQ

Which API versioning model should we choose?

If you have many external consumers you cannot contact, use a date-based header version with a published support window, as GitHub does with X-GitHub-Api-Version and its 24-month commitment. If you control every client, additive-only changes with no version header are cheaper. Decide before the first endpoint ships.

How long should we support an old API version?

GitHub supports a previous version for at least 24 months after a newer version is released, and lists 2022-11-28 as supported until 10 March 2028. That is a reasonable public benchmark. Shorter windows are defensible for internal APIs where you can enumerate and contact every consumer directly.

What is the difference between the Deprecation and Sunset headers?

RFC 9745 defines Deprecation as the date deprecation takes or took effect. RFC 8594 defines Sunset as the date the resource stops responding. RFC 9745 requires that the Sunset timestamp is never earlier than the Deprecation timestamp. Deprecation alone changes no behaviour at all.

Are HTTP APIs always cheaper than REST APIs on AWS?

On request pricing, yes by a wide margin: $1.00 per million against $3.50 per million on the first tier in US East as of August 2026. REST APIs carry features HTTP APIs lack, including response caching billed hourly and private API support through AWS PrivateLink. Model your feature needs first.

Why does OpenAPI 3.2.0 matter for our API?

Version 3.2.0, released 23 September 2025, added first-class descriptions for streaming responses using text/event-stream, application/jsonl, application/json-seq and multipart/mixed with the itemSchema keyword. It also added the query HTTP method and OAuth 2.0 Device Authorization Flow. A 3.1 description cannot describe a streaming endpoint accurately.

How do we find APIs we do not know about?

Compare a generated inventory from your OpenAPI descriptions against observed traffic at the edge. Cloudflare found 30.7% more endpoints through machine-learning discovery of all incoming traffic than customers self-reported. OWASP lists Improper Inventory Management as API9:2023 for exactly this reason.

What should an API security review cover as a minimum?

The OWASP API Security Top 10 2023, with object-level authorization tested per endpoint rather than per role. That list covers broken object and function level authorization, broken authentication, unrestricted resource consumption, server-side request forgery, security misconfiguration, inventory management, and unsafe consumption of third-party APIs.

Does the Digital Personal Data Protection Act change our API design?

It changes where consent and purpose live. Carrying consent state in the API contract rather than a side table means every consumer handles it consistently. We design applications aligned with DPDP Act 2023 requirements. Retrofitting this after launch means a schema migration across every consumer of the API.

How eCorpIT can help

We take API work from contract to production and stay for the operate-and-deprecate phase, which is where most of the value and nearly all of the risk sits. If you have an API that needs a versioning policy, a cost problem at the gateway, or an inventory you cannot fully enumerate, we can scope it in a short discovery engagement and give you an indicative band. Talk to our engineering team at /contact-us/.

References

1. REST API version 2026-03-10 is now available, GitHub Changelog, 12 March 2026.
2. API Versions, GitHub Docs, support windows, 410 Gone behaviour and the breaking-change list.
3. Amazon API Gateway pricing, Amazon Web Services, request tiers, data transfer and worked examples.
4. RFC 9745: The Deprecation HTTP Response Header Field, S. Dalal and E. Wilde, IETF, March 2025.
5. RFC 8594: The Sunset HTTP Header Field, E. Wilde, IETF, May 2019.
6. RFC 9457: Problem Details for HTTP APIs, M. Nottingham, E. Wilde and S. Dalal, IETF, July 2023.
7. Announcing OpenAPI v3.2, OpenAPI Initiative, 23 September 2025.
8. OpenAPI Specification v3.2.0, OpenAPI Initiative specification text.
9. OWASP Top 10 API Security Risks 2023, OWASP API Security Project.
10. API1:2023 Broken Object Level Authorization, OWASP API Security Project.
11. Introducing Cloudflare's 2024 API security and management report, Cloudflare, 9 January 2024, endpoint discovery and HTTP 429 share.
12. API upgrades, Stripe Documentation, release trains and the 72-hour rollback window.
13. To infinity and beyond: enabling the future of GitHub's REST API with API versioning, GitHub Blog.
14. Breaking changes, GitHub Docs, upgrade guidance per version.

Last updated: 17 August 2026.