Should I use one complex endpoint or several smaller ones for our service?

[PaisleyM]

I’m trying to decide between using a single, more complex endpoint or breaking the functionality into several smaller ones for our new service. I keep going back and forth on whether the added granularity is worth the extra calls a client would have to make.

[Ronald59]

I started with a single API surface and kept it heavy, but it soaked up complexity fast with auth, validation, and feature flags. It felt brittle when we added new paths.

[JacobEM]

We prototyped several smaller routes and wired the client to call them separately. Yes, there were more requests, but the team could pinpoint failures quickly and ship features faster. We tracked latency and error rates and, across the board, the numbers stayed in a similar range.

[Madison12]

Could the real issue be onboarding friction, caching, or authentication overhead, rather than just how granular the surface is?

[JoshuaD]

Another time I drifted into thinking about docs and SDK ergonomics more than calls. We tried a thin wrapper around multiple calls to hide the granularity, but it ended up feeling like false simplicity and we dropped it.