There are different subsets of people served by the Apigee API management platform.
- API Publishers - people who operate IN the Apigee administrative UI, to publish (share) APIs to developers. The mechanism of sharing is typically the "developer portal" which is a Web UI, that often delivers APIs via an e-commerce metaphor. Browse the catalog of products (= API products), examine one or more closely, then request credentials for that API product. There are typically o(10) publishers on an Apigee platform. Maybe 10 or so different people or groups publishing APIs. Of course every API program is different, and some might support 50 publishers, or 150. My guess of o(10) is vague and unscientific, just sort of illustrative.
- API Consumer Developers. - people who build apps using the APIs that are published or shared. These people build mobile apps, apps for embedded systems, headless apps for integration, and so on. In your case, "retail", with millions of consumers, the app will probably run on a mobile device like android or Iphone, or it will be accessible from a website. There will be o(50) consumer developers. Again, vague and unscientific. It varies from program to program.
- USERS of the app. This is the "millions of customers" .
There will be a separate devapp registered on the Apigee site for each revision of the app build by a developer. So , figure o(50) apps. Could be 100 apps, if each of 50 developers has 2 apps in production. Or it could be 200 apps, if each developer has 4 apps in the pipeline. But not millions.
How does Apigee authenticate the potentially millions of users that might take advantage of these apps? That's a job for an Identity Platform - either a custom-built one, or something like an Okta or Active Directory B2C tenant. Apigee doesn't directly authenticate end users of apps.
This is a longish screencast that shows how an IdP and Apigee can complement each other in this authentication effort.
LinkedIn
Twitter
