Hello everyone, I have a question concerning the API manager. So in the past we have mostly worked with API policy manager and creating Api Keys (associated with a role) for the consumers. My question: Which architecture or best practice do you use when it comes to creating and publishing APIs:
Create one API with api Keys (and roles so you can use expressions in the policies that they can only use certain endpoints) and send it secure to the consumer.
e.g I have an api key that is associated with role generalRead -> in the authorize by role policy I write the condition: request.method == "GET"
Create multiple small APIs and publish them with a subscription (subscriptions manager). So that you can manage which parts consumers can use of the APIs combined.
myapi-public (only allowed endpoints)
myapi-admin (restricted endpoints)
myapi-write (write endpoints)
Hi Jens, Thank you for your question. Best practice is to create multiple APIs (or API products) aligned to consumer intent and access level, and use subscriptions to control who can access what. Policies should remain simple and reusable, not overloaded with conditional role logic. This approach aligns with industry standards and is also the architecture APIM 3.0 is designed to support. Option 2 – Multiple APIs + subscriptions is the recommended approach What most teams do in practice is adopt a hybrid approach Use API / product boundaries for coarse access control Use policies for cross-cutting (different policy control areas) Avoid deep endpoint-level role logic unless it’s truly exceptional use case Think of policies as guardrails, not decision trees. If the rule is about security, protection, or observability ➡️ policy If the rule is about who can do what ➡️ API/product + subscription
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.
Hi Kams N., Adam, and Jens L., It should be possible to retrieve the current subscription user (calling the API) via the pipeline parameters. If this is not feasible, we won’t be able to deliver specific data to different consumers without creating multiple endpoints, routes in the main pipeline, or even separate pipelines. Consequently, we wouldn't be able to use the old or new subscription manager in most of our APIs for this reason. It shouldn't be too difficult to pass the client ID and email address of the subscription user through the pipeline parameters, right? 🙂 It would be a much-needed improvement! Best regards, Andreas
