Navigating API Gateway Pricing Models: Should You Consolidate Endpoints or Keep Them Distinct?

In the rapidly evolving landscape of API design, selecting the right gateway solution can significantly impact both your application’s architecture and operational costs. Recently, I encountered an intriguing challenge posed by a vendor that employs an “action-based” pricing model—charging based on the number of individual endpoints or “actions” your API exposes.

The Context

Our team is currently exploring various API gateway providers to enhance our backend infrastructure. During this process, one vendor highlighted a potential concern: their pricing structure depends on the count of distinct actions or endpoints. In our existing setup, our controllers—such as WidgetsController—feature standard CRUD actions like CreateWidget, GetWidgets, UpdateWidget, and DeleteWidget. Additionally, we sometimes define specialized actions tailored for specific use cases, for example, GetWidgetsForUseCase1 and GetWidgetsForUseCase2. These are not just duplicated logic; they serve to clearly delineate different business workflows and improve code clarity.

Our backend architecture strives to remain DRY (Don’t Repeat Yourself), centralizing shared logic within service layers. The separate, use-case-specific endpoints primarily exist to enhance maintainability and explicitness, rather than redundancy.

The Vendor’s Perspective

This vendor recommends consolidating similar endpoints by introducing parameters or flags that modify request behavior. They suggest leveraging their tooling at the gateway to manage this internal complexity. From their standpoint, fewer endpoints could simplify the API surface and potentially optimize performance.

However, this approach raises red flags for us. It feels more like a strategic move to encourage vendor lock-in and optimize their pricing, rather than a genuine architectural best practice. We’re concerned about trading clarity for potential cost savings, especially since some use cases will demand responses with significantly different data structures.

The Future and Its Implications

Further complicating the decision, we are contemplating adding new actions and endpoints to accommodate future features. These new endpoints might return responses that differ substantially based on the request context. This raises an important question: Should we keep our endpoints narrowly focused for clarity and maintainability, or consolidate them into more complex, flexible endpoints to potentially reduce costs?

Key Considerations

• Architectural and Performance Benefits: Is there concrete value in merging multiple specific actions into a single, multifaceted endpoint? Would this improve performance or simplify client consumption?

• Maintainability and Readability: Does consolidating endpoints compromise code clarity,