Navigating API Gateway Pricing: To Consolidate or Keep Actions Distinct?

When designing robust APIs, one of the key considerations is how to structure endpoints most effectively. Recently, I’ve been exploring API gateway solutions, but a particular concern has caught my attention: some providers charge based on the number of “actions” or “endpoints” exposed. This raises important questions about API architecture and cost management.

The Challenge with Action-Based Pricing

In our current development approach, we maintain controllers—such as a WidgetsController—with clearly defined actions like CreateWidget, GetWidgets, UpdateWidget, and DeleteWidget. Additionally, we sometimes create specialized actions tailored to specific use cases, such as GetWidgetsForUseCase1 and GetWidgetsForUseCase2. These actions often encapsulate distinct business logic aligned with particular client requirements.

It’s worth noting that our backend strives for a DRY (Don’t Repeat Yourself) structure. Shared logic resides primarily in service layers, while controllers act as coordinators for specific workflows. The separate actions are mainly for clarity, organization, and separation of concerns, not due to redundant code.

The Vendor’s Perspective

Some API gateway vendors suggest consolidating multiple specific actions into fewer, more flexible endpoints that interpret parameters or flags to handle different behaviors. They also promote using their tooling to manage internal logic at the gateway level, potentially reducing the total number of endpoints.

While this approach might seem to simplify the API at first glance, it raises concerns about increased complexity within endpoints and possible vendor lock-in. It may also lead to endpoints becoming overly broad, handling diverse scenarios that could be better served by focused, self-descriptive URLs.

Future Considerations

Our team is also contemplating expanding the API with additional actions that return markedly different response structures based on request parameters. This evolution adds another layer of complexity: Should we cram multiple behaviors into fewer endpoints, or keep each action narrowly scoped?

Your Insights

Given these considerations, I’m eager to hear from experienced API designers and architects:

• Is there a tangible performance or maintainability benefit to merging multiple specialized actions into a consolidated, flexible endpoint?
• Or does maintaining granular, purpose-specific endpoints promote clarity, easier debugging, and better scalability—even if that means increasing the total number of endpoints?
• Have you navigated similar situations where pricing models incentivized fewer endpoints? What strategies did you find most effective?

Your guidance and real-world examples would be invaluable as we weigh these architectural