API Modernization Without a Big Bang: OpenAPI and Strangler Fig

API modernization means upgrading your API contracts, security and delivery platform so legacy systems can ship faster, scale and stay safe. We recommend an iterative, design-first approach built on the OpenAPI Specification, hardened against the OWASP API Security Top 10, and, for large legacy systems, executed with the Strangler Fig pattern, the way we do at Dogtooth Inc.

TL;DR:

With weak consumer visibility, put a gateway and facade first; use Strangler Fig for large, critical systems, and rewrite only unsupported or unsafe platforms.

Prioritize authorization: three of OWASP’s top five API risks involve broken access control, so enforce checks where data is owned, not just at gateways.

Define OpenAPI contracts before coding; start with the five busiest endpoints and generate mocks, tests, and documentation from each contract.

Prefer additive changes; version only unavoidable breaking changes, and announce retirement with Deprecation and Sunset headers plus telemetry for each account over multiple quarters.

Set a baseline before coding and track three to five measures, such as onboarding time, API change incidents, and traffic through the managed gateway.

What does API modernization mean today?
What business benefits should you expect?
Which modernization approach fits your situation?
Why should you design APIs contract-first?
Which security risks come up during modernization?
How do you handle versioning, deprecation and consumer communication?
What do implementation patterns and API management look like at scale?
What phases make up a practical modernization roadmap?
How do you measure whether modernization is working?
How does Dogtooth Inc. approach API modernization in practice?
How should you test modernized APIs?
Where do AI and automation fit in API modernization?
How do you keep backward compatibility during modernization?
How do you handle data migrations and protect data integrity?
Author perspective: where should year-one resources go?
How can we help with your API modernization?
FAQ
Sources

What does API modernization mean today?

At its core, API modernization is the work of bringing an API estate up to current engineering practice. That covers three layers at once: the API surface (the endpoints, resources and naming consumers see), the contracts (machine-readable descriptions of requests, responses and errors), and the platform underneath (gateways, authentication, observability and deployment). Updating only one layer rarely pays off. A clean new endpoint behind a brittle, undocumented gateway still breaks partners.

Modernization also connects to how companies build software now. Many teams are moving from a single large application toward smaller services, and they treat their APIs as products with owners, documentation, versioning and onboarding paths. That shift puts developer experience at the center: an API that a new engineer cannot call successfully without substantial effort is costing you integration revenue.

A newer driver is agentic integration. AI agents discover and call APIs the way developers do, but with less tolerance for ambiguity. They depend on precise schemas, consistent errors and predictable behavior. If your legacy API relies on tribal knowledge, an agent will misuse it. If you want to see how we think about safe agent access, our piece on AI agent safety and enterprise runtime controls covers it in depth.

Here is what modernization typically includes:

Contract-first definitions so every endpoint has a reviewed, machine-readable description before code is written.
Consistent security with centralized authentication and authorization rather than per-service logic.
Observability that shows who calls what, how often and with which version.
Gateway and routing layers that let you move traffic between old and new implementations without consumer changes.
Documented lifecycle rules for versioning, deprecation and retirement.
Developer-facing assets such as a portal, sandbox, mocks and sample code.

The business drivers are usually concrete. A partner wants to integrate and your team quotes a lengthy timeline because nobody can explain the legacy behavior. A security review flags endpoints no one owns. A mobile release is blocked because a backend change might break an unknown consumer. Each of these is a modernization trigger, and each maps to a measurable outcome: shorter integration time, a known API inventory, and safer releases.

You do not need to rebuild everything to qualify as modernizing. Most successful programs start with the handful of APIs that carry the most traffic or revenue, wrap them in better contracts and controls, and expand outward as the team builds confidence.

What business benefits should you expect?

The case for modernization is easiest to defend when you tie each benefit to something your finance or product leaders already track. Here are the outcomes we see teams validate most often:

Faster time-to-market. With contracts defined up front, frontend, backend and partner teams work in parallel against mocks instead of waiting on each other. New integrations stop requiring a guided tour of legacy code.
Higher developer productivity. Generated documentation, clients and tests remove hours of repetitive work per endpoint. Engineers spend more time on features and less on reverse-engineering behavior.
Lower maintenance cost and less technical debt. Retiring duplicate, undocumented and unused endpoints shrinks the surface you have to patch, monitor and support.
Better reliability and scalability. Modern gateways, rate limits and observability let you absorb traffic spikes and find failures before customers report them.
Easier partner enablement. A documented, versioned, sandboxed API turns partner onboarding from a project into a self-service task.
Reduced operational risk. Central authorization, validated payloads and a real inventory close the gaps attackers look for.

Security deserves special weight in the budget conversation, because it changes the cost of doing nothing. The OWASP team’s 2023 update to its API list makes the pattern plain:

Authorization remains the primary API security challenge, with three of the top five risks tied to broken access control. If your legacy endpoints enforce access rules inconsistently, modernization is the cheapest moment to fix that, because you are already touching the contract and the gateway.

It is worth being honest about how benefits arrive. Speed and productivity gains show up gradually, as each modernized API gets used. Cost reduction lags further, because you often run old and new side by side during a transition. Security improvements can appear quickly for the endpoints you prioritize, but only for those. Set expectations by API group rather than promising a single date when everything improves.

Also decide in advance how you will prove the value. Pick two or three leading indicators before you start, such as time to onboard a new integration, number of production incidents tied to API changes, and share of traffic served through the managed gateway. Without a baseline, “faster” and “safer” remain opinions. We cover the measurement side in more detail later in this guide.

Finally, link benefits to sequencing. The highest-return modernization targets are usually the APIs with many consumers, frequent change and real security exposure. Starting there produces visible wins that fund the harder, quieter work on internal and low-traffic interfaces.

Which modernization approach fits your situation?

There is no single correct path. The right approach depends on how many consumers you have, how well you can observe them, what compliance obligations apply and how much business impact an outage would cause. These are the four patterns we see most often, ordered roughly from least to most invasive:

Wrap with an adapter facade. You place a modern API layer in front of the legacy system. Consumers get clean contracts and consistent security while the old logic keeps running underneath. This is the fastest way to expose a legacy system safely, and it works well when the backend is stable but its interface is awkward. The limit is that you inherit the legacy system’s performance and defects, and the facade can become permanent if nobody plans the next step.
Replace incrementally with the Strangler Fig pattern. You build new functionality around the legacy system and shift traffic to it module by module. As described in Martin Fowler’s write-up of the Strangler Fig pattern, a gateway routes requests to old or new implementations until the legacy host can be retired. This lowers risk because every slice is small, reversible and testable with real traffic.
Rewrite or replatform. You rebuild the system on a new foundation. This is justified when the legacy platform cannot be run safely, when its technology is unsupported, or when the domain model is so wrong that wrapping it would lock in the damage. The trade-off is time and risk: you carry two systems, and feature parity is harder to reach than anyone estimates.
Lift and shift. You move the existing system to new infrastructure with minimal change. It can buy time, reduce hosting cost or meet a data center deadline. It does not modernize the API itself, so treat it as a holding action, not a destination.

To choose among them, answer these questions honestly:

How many consumers call this API, and do you know who they are?
Do you have per-consumer telemetry, or are you guessing?
Do compliance or audit rules limit how you can change data flows?
What is the revenue or operational cost of an hour of downtime?
Is the legacy code understood by anyone still on the team?

If you have many consumers and weak telemetry, favor a facade first so you can start measuring. If the system is business critical and large, favor the Strangler Fig. Reserve a full rewrite for cases where the other options clearly fail.

Pro Tip: Whatever you choose, put a gateway in front of the legacy system first. It gives you routing control, telemetry and a rollback switch before you change a single line of business logic.

Why should you design APIs contract-first?

Design-first means you write and agree on the API description before anyone writes the implementation. The OpenAPI Specification, whose 3.2.x series is the current standard for defining language-agnostic HTTP API interfaces, is the usual format. Because the contract is machine-readable, tools can read it and do real work: generate documentation, build clients and servers, create tests and validate traffic.

For a modernization project, that matters more than for a greenfield one. Legacy APIs often have behavior that exists only in code and in the memory of whoever last touched it. Writing the contract forces that behavior into the open, where product owners, security reviewers and consumers can challenge it before you commit.

The practical benefits look like this:

Parallel work. Frontend and partner teams build against mock servers generated from the contract while the backend catches up.
Living documentation. Docs come from the same file that drives validation, so they stop drifting from reality.
Code generation. Client libraries and server stubs reduce hand-written boilerplate and the typos that come with it.
Automated testing. Contract tests compare real responses to the description, catching accidental breaking changes early.
Review at the right time. Naming, error formats and auth requirements get debated in a pull request on a YAML file, not in a production incident.

A well-defined description also reduces guesswork for consumers. As the OpenAPI 3.2.1 specification notes, OpenAPI descriptions allow tools to generate documentation, clients, servers and tests, which supports automation across design, testing and runtime validation.

One runtime practice deserves its own mention: validating payloads strictly against the schema. Rejecting requests and responses that do not match the contract is a first line of defense against malformed input and a signal that something has drifted. Industry guidance treats design-first development and strict schema validation as practices that prevent inconsistencies and runtime errors.

The OpenAPI Specification 3.2.x series is the current standard for describing HTTP APIs. Adopting it means your contracts will work with the widest range of documentation, testing and gateway tooling.

A practical starting point: write OpenAPI descriptions for your five busiest endpoints, even if the implementations stay untouched. Publish them internally, have consumers review them, and use the corrections as your first real picture of how the API is actually used.

Which security risks come up during modernization?

Modernization is the best moment to close security gaps, because you are already revisiting contracts, gateways and ownership. The OWASP API Security Top 10 2023 gives a useful priority list, and several items map directly onto modernization work.

Authorization comes first. The list includes Broken Object Level Authorization (API1:2023), where an API lets a caller reach another user’s records by changing an identifier. Legacy systems are prone to this because access checks were often added endpoint by endpoint over many years. The same list covers Unrestricted Access to Sensitive Business Flows (API6:2023), where automation abuses a legitimate workflow such as booking or checkout.

Unsafe consumption of APIs is the notable 2023 addition. It reflects attackers targeting the third-party services you integrate with, on the assumption that developers trust upstream data more than they trust user input. If your modernized API calls partners, payment providers or data vendors, treat their responses as untrusted input.

Other risks to watch include server-side request forgery (SSRF), security misconfiguration and improper inventory management. Inventory is the quiet one: forgotten old versions and shadow endpoints stay live and unpatched because nobody remembers them. OWASP’s own release notes for the 2023 edition document how API traffic and integration complexity grew between editions, which raised exposure to object-level authorization failures and excessive resource consumption.

The mitigations are practical and mostly architectural:

Centralize authentication and authorization at the gateway or a shared policy layer instead of re-implementing it per service.
Enforce object-level checks in the service that owns the data, not only at the edge.
Apply rate limits and quotas to blunt scraping, credential stuffing and resource exhaustion.
Validate every payload against the OpenAPI schema, inbound and, for sensitive flows, outbound.
Treat third-party responses as untrusted and validate them before using them.
Restrict outbound requests from services that fetch URLs to reduce SSRF exposure.
Maintain a live inventory of every endpoint, version and owner, fed by telemetry rather than a spreadsheet.

Pro Tip: Run your gateway logs against your documented API list. Any endpoint that receives traffic but is missing from the inventory is a priority finding, and often the first real security win of the program.

How do you handle versioning, deprecation and consumer communication?

Evolving an API without harming consumers depends on one habit: classifying every change before you ship it. Practitioner guidance such as the Evolving an API Design playbook sorts changes into three groups. Additive changes, like a new endpoint or optional field, are the most common and generally safe. Behavioral changes alter how existing calls act without altering their shape, and they are easy to underestimate. Breaking changes remove or alter things consumers rely on.

A simple rule follows. Prefer additive evolution whenever you can. Require a new version only when a breaking change is unavoidable, and treat behavioral changes with the same caution as breaking ones until telemetry shows nobody depends on the old behavior.

For retirement, use standard signals rather than a surprise email. The Deprecation and Sunset HTTP response headers, defined in RFCs, let you tell every caller programmatically that an endpoint is on its way out and when it will stop working. Pair them with per-account telemetry so you know exactly which consumers still call the old version.

A workable timeline looks like this:

Announce. Publish the change, the replacement and the sunset date in release notes and to registered contacts, and begin sending the headers.
Reach out in stages. Contact the heaviest remaining consumers directly, then smaller ones, offering migration help where it removes friction.
Review telemetry on a schedule. Check weekly or monthly which accounts still call the old version and whether usage is falling.
Hold a long sunset. Keep the old version running through the announced window, extending it for a critical consumer if the business case warrants.
Retire and confirm. Turn the endpoint off, watch for errors, and keep a fast rollback path for a short period.

Guidance for breaking changes calls for multi-quarter deprecation timelines backed by per-account telemetry and the Deprecation and Sunset headers. A sunset date without usage data is a guess, and a guess can cost you a partner relationship.

The cultural point is as important as the mechanics. Consumers forgive change they were told about early, saw in their own logs and had time to handle. They rarely forgive a silent break, however justified.

What do implementation patterns and API management look like at scale?

Once you move beyond a pilot, the question shifts from “how do we build this API” to “how do we run hundreds of them without chaos.” The answer is a clear split between the gateway, which handles runtime traffic, and the control plane, which handles configuration, policy and lifecycle. Keeping them separate lets you deploy gateways close to workloads, in the cloud, on premises or in a hybrid mix, while managing policy from one place.

Key patterns and concerns to plan for:

Gateway and control plane separation. Gateways enforce authentication, rate limits, routing and transformation. The control plane stores definitions, pushes policy and reports status. This separation is what makes flexible, hybrid deployments practical for organizations with data residency or latency constraints.
Routing for incremental replacement. The gateway is also the mechanism behind the Strangler Fig. Route rules send some paths, accounts or percentages of traffic to new services while the rest continue to the legacy backend.
API productization. Treat each API as a product with an owner, a roadmap, usage plans and a support path. Subscription controls let you issue keys, set quotas by plan and revoke access cleanly.
Developer portal. A single place with documentation generated from OpenAPI, sandbox access, sample code and changelogs. It is the front door that makes partner onboarding self-service.
Monitoring and logging. Request-level metrics, error rates and latency by endpoint and by consumer. This is the raw material for SLOs, security reviews and deprecation decisions.
Discovery and governance. Automated discovery of endpoints from gateway traffic keeps the inventory honest, and lightweight review rules keep new APIs consistent in naming, errors and security.

Partner and B2B integrations deserve a note. Many organizations still exchange data with trading partners over older channels such as EDI while newer consumers expect real-time APIs. Our partners at Ampwise AI describe how to run EDI at the partner boundary and use APIs for real-time B2B data, which is a useful frame for deciding which interface belongs where during a long transition.

When you evaluate cloud-based API services or management platforms, weigh them on the capabilities above rather than on feature count: can they run gateways where your workloads live, do they expose a clean control-plane interface, and can they feed telemetry into the tools your team already uses? A platform that makes deprecation data easy to query will save you more time than one with a longer feature list.

What phases make up a practical modernization roadmap?

A roadmap gives executives something to budget, schedule and measure. We break modernization programs into phases, and we recommend overlapping them rather than running them as a strict waterfall.

Discovery and assessment. Inventory every endpoint, version, owner and consumer. Use gateway logs and code scanning to find what the documentation misses. Rate each API by traffic, revenue impact, security exposure and change frequency. The output is a ranked list, not a report nobody reads.
Strategy and prioritization. Choose an approach per API group, whether facade, Strangler Fig, rewrite or leave alone. Sequence by business value and risk, and agree on success measures and a baseline. This is also where you decide what you will not modernize, which is often the most useful decision.
Design and contract-first work. Write OpenAPI descriptions, stand up mock servers and add consumer-driven contract tests. Review security requirements, error formats and versioning rules before implementation begins.
Pilot, iterate and roll out. Pick one valuable but contained slice and run it end to end. Shift traffic gradually, such as a small percentage of requests or a single internal consumer first, and compare behavior against the legacy path. Widen the rollout as confidence and telemetry support it.
Operate. Define service-level objectives for latency, errors and availability, assign owners, and run regular governance reviews. Use telemetry to drive deprecation and sunsetting of the old paths, so the program ends with retirement, not two permanent systems.

Timelines depend heavily on scope, so we avoid quoting a universal duration. What we can say is that the pilot in phase four teaches you more than any amount of planning, so get there early. An early first slice also protects executive sponsorship.

Phased migration is a theme we have written about more broadly. Our guide to legacy system migration in five phases covers how to avoid a risky big-bang cutover, and the same discipline applies to APIs.

Pro Tip: Fund the program in stages tied to outcomes, such as “first modernized API in production” and “first legacy endpoint retired,” rather than as one large annual budget. Each stage then has a visible deliverable and a natural checkpoint.

How do you measure whether modernization is working?

Decide your metrics before the first line of code, or you will end up arguing about whether the project helped. We group useful measures into a few categories.

Adoption. Active consumers per endpoint and the share of traffic using modernized versus legacy paths. A modernized API nobody calls has not delivered value.
Service-level objectives. Latency, error rate and availability per API, tracked against targets you set with the teams that own them.
Delivery velocity. Time to ship a change, time to onboard a new integration and the number of incidents caused by API changes.
Cost signals. Maintenance effort, infrastructure spend on legacy components and support tickets tied to API confusion.
Per-account telemetry. Which specific accounts still call deprecated versions, how often and from which clients. This is the evidence that makes sunsetting safe.
Business KPIs. Partner activation time, revenue through integrations and developer productivity measures your leaders already watch.

Per-account telemetry is the backbone of safe retirement. Practitioner guidance ties multi-quarter deprecation timelines to it, because aggregate traffic numbers hide the one critical customer still calling an old endpoint.

Resist the temptation to track everything. Three to five metrics that your sponsors understand will do more than a dashboard with forty panels. Review them on a fixed cadence, and use them to decide whether to proceed, pause or change course on the next slice.

How does Dogtooth Inc. approach API modernization in practice?

We build and migrate platforms for brands with real operating volume, so these methods come from client work, not theory. Here are the credentials most relevant to API modernization:

Legacy migrations. We work on legacy migrations, helping clients modernize aging platforms.
AI booking system. We built an AI booking system that books sessions, charges cards and sends invites across brands, which depends on dependable API contracts.
Tracking infrastructure. We implemented Meta CAPI tracking across ad accounts, an event-driven integration that needed careful schema and delivery handling.
Retained support. Our team stays on after launch, so deprecation and optimization are handled by the people who built the system.

Our typical approach starts with a design-first contract, a pilot slice routed through a gateway in Strangler Fig fashion, and telemetry that tells us when old paths can be retired. We keep the first release small so a client sees a working modernized endpoint quickly.

What an engagement can produce is a faster release cadence, because consumers have clear contracts and changes are tested before they reach production. We describe these outcomes qualitatively and without client-identifying detail, because every estate is different.

How should you test modernized APIs?

Modernized APIs need testing that matches how they are built. Three layers do most of the work.

Contract testing checks that real requests and responses match the OpenAPI description. Provider-side tests confirm the service honors its published contract. Consumer-driven tests let each consumer declare what it depends on, so a provider team learns immediately when a change would break someone. This is the cheapest way to catch accidental breaking changes.

Integration testing exercises the API together with its real dependencies: databases, queues, authentication and third-party services. For a modernization project, run the same scenarios against both the legacy and modernized paths and compare outputs. Differences are either bugs or undocumented legacy behavior worth deciding on consciously.

Traffic-based verification uses mirrored or replayed production requests against the new path before real users depend on it. Combined with gradual traffic shifting, it reveals edge cases no test author imagined.

Add security checks to the same pipeline: schema validation of payloads, authorization tests that try to reach another account’s objects, and rate-limit checks. Because OpenAPI descriptions can drive generated tests, each endpoint you describe also becomes easier to test, which compounds the value of the contract-first investment.

Where do AI and automation fit in API modernization?

AI and automation help in two distinct ways: speeding up the modernization work itself and changing who calls your APIs.

On the work side, automation can draft first-pass OpenAPI descriptions from traffic logs or code, flag endpoints missing from the inventory, generate test cases from contracts and summarize telemetry into deprecation reports. These are accelerators, not replacements for review. A person should confirm that a drafted contract reflects intended behavior, not accidental legacy quirks.

On the consumption side, AI agents increasingly call APIs directly. They need precise schemas, consistent error messages and clear descriptions of what each operation does, and they punish ambiguity by guessing. An example from our partners at Assymetrix shows the pattern: their prediction market API guide for AI agents emphasizes canonical schemas and discovery so agent pipelines can run reliably in production.

Agents also raise safety questions: what can they invoke, with what credentials and under whose supervision? We cover runtime controls in our article on enterprise AI agent safety and oversight patterns in humans in the loop. Our own AI agents work inside real client workflows, drafting, checking, booking and reporting, and we apply the same contract and authorization discipline to them as to any other consumer.

How do you keep backward compatibility during modernization?

Backward compatibility is what lets modernization happen while the business keeps running. The core strategies are straightforward, even if the discipline is hard.

Prefer additive change. Add fields and endpoints instead of renaming or removing them. Make new request fields optional with sensible defaults.
Be liberal in what you accept. Tolerate unknown fields from consumers and avoid rejecting requests over harmless differences, while still validating what matters for security.
Freeze behavior, not just shape. Behavioral changes break consumers as surely as removed fields. Pin existing behavior with contract tests, and change it only through an announced version.
Use the facade as a compatibility layer. A gateway or adapter can translate between the old contract and the new implementation, so consumers keep calling what they know while the backend changes behind it.
Version deliberately. When a break is unavoidable, introduce a new version alongside the old one and run both until telemetry shows the old one is idle.
Communicate with headers and data. Send Deprecation and Sunset headers, and use per-account telemetry to reach the consumers who still depend on the old behavior.

The common failure is assuming nobody uses an obscure field or quirk. Consumers do, often in ways the original developers never intended. Telemetry and consumer-driven contract tests replace that assumption with evidence.

How do you handle data migrations and protect data integrity?

Data is usually the hardest part of an API modernization, because APIs can be swapped gradually but a database has one source of truth. A few practices keep that transition safe.

Start by deciding which system owns each piece of data at each stage. During a Strangler Fig migration, ownership moves slice by slice, so write down the rule: for this entity, the legacy system owns writes until a specific cutover, then the new service does. Ambiguity here produces duplicates and lost updates.

Then choose a synchronization approach that fits the risk. Common options include a one-time migration with a short freeze window, continuous replication from legacy to new storage while both run, and dual writes with reconciliation. Dual writes are tempting but fragile, so pair them with automated comparison jobs that flag mismatches.

Three approaches to synchronizing migrated data

Validate aggressively. Compare record counts, checksums and sampled records between systems, and run the same read queries against both. Treat discrepancies as release blockers for the affected slice. Keep the schema contract explicit too, using the OpenAPI description to define field types, formats and required values so bad data is rejected at the edge.

Finally, rehearse the rollback. Know how to route traffic back to the legacy path and how to reconcile writes made to the new one. Our migration work, including moving three Keap accounts to Maropost, relied on this kind of staged validation, because the goal is a cutover customers never notice.

Author perspective: where should year-one resources go?

With a limited budget, I would resist the instinct to start with the most technically interesting system. Start with the consumer-facing, high-traffic flows, because that is where improvements are visible and where failures are expensive. Executives fund what they can see.

I would spend early money on OpenAPI contracts and telemetry before a full rewrite. A described, measured API is something you can reason about, secure and migrate. An undescribed one is a guess no matter how modern the code behind it looks. Teams that skip this step tend to rebuild the same confusion on a newer stack.

And I would favor staged strangler replacements with long sunsets over big-bang breaks. Patience reads as slow in a planning meeting and as reliability in a partner’s incident log. The fastest program is the one that never has to roll back a release.

— Chase Weir

How can we help with your API modernization?

If your integrations take months to quote, your endpoints lack owners or a legacy platform is holding back releases, we can carry the plan above through to production. Our Platform Builds & Migrations and Integrations & APIs services cover contract design, gateway-led strangler pilots, security hardening and telemetry-driven retirement, with a team that stays on after launch.

Dogtoothinc

You can start with a look at how we handled a Drupal 6 research platform migration, then book an exploratory conversation about your own API estate on our services overview. We will tell you where we would begin.

FAQ

What does API stand for?

API stands for application programming interface. It is a defined way for one piece of software to request data or actions from another. Standards such as the OpenAPI Specification describe those interfaces in a machine-readable form.

What are the main stages of an API modernization program?

We use a phased approach: discovery and assessment, strategy and prioritization, design and contract-first work, pilot and rollout, and ongoing operation. The pilot phase teaches the most, so reach it early. Governance and telemetry-driven retirement keep the program from leaving two systems running forever.

What are the four types of APIs?

APIs are commonly grouped by audience: public (open to any developer), partner (shared with specific business partners), private or internal (used inside one organization) and composite (combining several calls into one). Each type calls for different security, documentation and deprecation rules. Partner and public APIs usually need the longest sunset windows.

What will replace APIs?

Nothing is replacing APIs. Newer styles and consumers, including AI agents, are changing how interfaces are described and called, which makes precise contracts more important. Clear schemas and consistent behavior matter more as automated callers grow.