Hi Jens L., it looks like Kams has given some great feedback. I also have some feedback from one of our partners experienced in APIM but just starting to assess subscriptions. I think when he says “one API,” he’s really referring to one APIM Service or endpoint that exposes multiple methods. In most use cases, having different permissions based on the HTTP method within a single API works well and is often the simplest approach. Defining those rules using policies inside one Service is perfectly reasonable. Where subscriptions come in is at a different layer. My understanding is that subscriptions control which Services a consumer can access from the portal, while policies and roles control what a consumer can do within a Service at runtime. They solve different problems and are not really alternatives. From an architecture perspective, subscriptions are better suited for coarse-grained access (which Services are exposed), while policies handle fine-grained control within a Service. Splitting into multiple Services only really makes sense when there are clearly different consumer groups or when certain functionality should not be exposed at all to some consumers. Otherwise, creating many small APIs can add unnecessary overhead.
