Should I use an API gateway to expose legacy APIs to modern clients?

Usually, yes — if you need to modernize access without rewriting the legacy system. An API gateway can be a good way to expose legacy APIs to modern clients, but it’s not automatically the right choice in every case.

Good reasons to use an API gateway

• Hide legacy complexity: Present a clean, modern API to clients while keeping legacy endpoints unchanged behind the scenes.
• Protocol translation: Convert between REST/JSON and older styles like SOAP, XML, or even proprietary interfaces.
• Security: Centralize auth, rate limiting, TLS, token validation, and auditing.
• Versioning and compatibility: Support modern API versions without forcing clients to know legacy details.
• Aggregation: Combine multiple legacy calls into one client-friendly endpoint.
• Observability: Add logging, metrics, tracing, and monitoring in one place.

When it makes sense most

• You have multiple client apps that need the same legacy data.
• The legacy system is hard to change or risky to modify.
• You want a gradual modernization path.
• You need a stable public interface in front of unstable internal systems.

When it may be a bad idea

• The legacy API is simple and only used by one internal app.
• You would only be adding the gateway as an extra hop with little benefit.
• The gateway becomes a large transformation layer, turning into a mini-monolith.
• Performance is extremely sensitive and the extra latency matters.
• You actually need to refactor the legacy service rather than wrap it.

Important design caution

Don’t let the gateway become a place where all business logic lives. A gateway should mainly handle:

• routing
• authentication/authorization
• request/response shaping
• throttling/caching
• protocol translation

If it starts doing heavy business rules, you’ll create a maintenance bottleneck.

Often the best pattern

For many legacy-modernization efforts, the best approach is:

• API gateway for cross-cutting concerns and routing
• Backend-for-Frontend (BFF) if each client type needs different shapes of data
• Adapter/service layer to isolate legacy quirks
• Gradual replacement of legacy endpoints over time

Rule of thumb

Use an API gateway if you want to protect and modernize the interface to a legacy system.
Skip it if you just need a direct, internal integration and don’t gain enough from the abstraction.

If you want, I can help you decide with a quick checklist based on your specific legacy system and client needs.