How many operations should my API contain?

When we design APIs, one of the most important questions we face is: How many operations should we include in a single API? It may sound simple, but the answer shapes how easily others use our API, how we secure it, and how we maintain it over time.

In this post, we’ll walk through the key things we need to think about before deciding. 

1. Know the API’s Purpose

Every operation must belong somewhere. In our API led connectivity model, we will build APIs in layers:

• Experience APIs serve user interfaces like mobile apps, web apps or web sites
• Process APIs combine data from many sources for orchestration and aggregation
• System APIs connect to backend systems.

We must not mix layers. If an operation pulls customer data from a database, it belongs in a System API—not in the same API that handles screen layouts for mobile users.

2. Respect the Bounded Context

A good API respects business boundaries. We should group operations that serve one business capability. For example, in a Banking context:

• A Customer API should manage customer profiles.
• A Payments API should handle payments, direct-debits and transactions.
• A Loan API should manage loan applications and approvals.

If we put all these into one API, we create confusion. We also slow down teams that only care about one thing.

3. Think About the API Consumers

Who uses our API? Do they need the same operations?

• Internal teams might need detailed operations or operations for resources management.
• Mobile apps may only need summaries or operations to list/view data

If the consumers are different, we should split the APIs. Each API becomes smaller and more focused. That makes it easier to understand, test, and secure.

4. Keep It Manageable

There’s no hard limit. But once an API has more than 10 to 15 operations, it becomes harder to use.

• Developers struggle to find the right operation.
• Tests take longer.
• Changes become riskier.

We should aim for clarity. Smaller APIs are easier to maintain and secure.

5. Align with Team Ownership

If different teams own different operations, we should separate them.

• A Cards Team should not have to wait for a Transactions Team to approve a release.
• When each team owns its own API, work moves faster and with fewer risks.

6. Consider the Release Lifecycle

Some operations change more often than others. For example:

• Regulatory updates (like KYC rules) may be urgent.
• Business updates (like launching a new card product) follow product cycles.
• UX changes (like updating mobile flows) may happen weekly.

If we group all operations in one API, we tie everything to the slowest-moving part. Instead, we should map out the lifecycle of each operation and group them by release needs.

Operation type	Purpose	Expected Change Frequency
onboarding	Flows like KYC, registration	High
accounts	List/view accounts	Low
cases	Open/support cases	Medium
risk-assessment	Risk score calculation	High
customer	Read/update personal data	Medium

7. Design for Security

More operations mean a larger surface for attacks. When we’ve got too many operations, It’s harder to apply security rules per resource. And we can’t throttle some flows without affecting others.
Smaller APIs help us apply fine-grained controls. We can set custom SLAs, rate limits, and access policies.

8. Protect Critical Operations

Some operations are more important than others.

• A “make payment” operation is critical.
• A “list offers” operation is non-critical.

We must then separate critical from non-critical in our design.
This allows us to:

• Assign more CPU or memory to the critical APIs.I
• Set faster autoscaling rules.
• Apply strong protection (e.g., circuit breakers, strict rate limits).

Operation Example	Frequency	Business Criticality	Resource Impact
GET /products	Very high	Low	Low–Medium
GET /orders	High	Medium	Medium
POST /purchase	Medium	Very High	High (IO + writes)
POST /payments	Low–Medium	Very High	High
GET /customer/{id}	Medium	High	Medium

If necessary, we can define Traffic Policies required per operation (Rate limiting, throttling, circuit breaking…) and prioritize the critical ones. For example:

Operation	Policy Example
GET /products	Throttle to 500 req/s
GET /orders	Throttle to 100 req/s/user
POST /purchase	No throttle, priority route, retry on failure
GET /offers	Cached, limited SLA

Define SLAs per Operation or Resource Tier:

Tier	Resource	Description
Platinum	POST /purchase, POST /payment	Guaranteed 99.99% uptime, no throttle
Gold	GET /orders, GET /customer	99.9%, soft throttle
Silver	GET /products, GET /offers	Best-effort, throttled during spikes

In Summary

APIs are tools. If we design them with care, they become strong, fast, and clear. Group operations that belong together. Split them when they grow apart.
We must think about structure, change, speed, and users. This is the heart of API design. Not just code—but clarity, balance, and purpose.