Introduction
This document describes Developer Portal User Experience and Developer Portal workflows, when APIs packaged in API Products by the Sentinet Administrative Console users, are published for external or internal consumption through the Developer Portal as an API Catalog. Developer Portal offers self-service for its users combined with the flexibility of Sentinet Administrative Console Users to control Developer Portal workflows.
There are 5 Developer Portal entities that Developer Portal user deals with. Their short description is below:
API Product -- a collection of one or more APIs that make up an API Product.
Note
API Products and their APIs are managed by the API Provider. Developer Portal users do not have control over API Products’ life-cycle, content or their visibility in the Developer Portal API Catalog.
Consumer -- represents an organization, a company or some other group of people that will share the same Consumer account in the Developer Portal. As an example, you can think of a Consumer account as an API Provider's business partner account created by a business partner company which consumes providers API Product(s).
Developer User -- a user of a Consumer account in the Developer Portal. A Consumer account may have many user accounts (user logins) with different access rights. A Developer User is the one that logs in to the Developer Portal Web Application.
Subscription -- a subscription is a consent between API Provider and API Consumer (Developer Portal Consumer account) to access provider's API Product. A Subscription is a relationship between Consumer account and an API Product. A Consumer account can have one or more Subscriptions to the same API Product, as well as many Subscriptions to different API Products.
Application -- is an associative entity(s) that Developer Users create for their Subscriptions in order to consume API Products via these Subscriptions. When Consumer "application" calls API(s) in an API Product, they typically submit an API Key that uniquely identifies API Consumer and his specific Subscription. Sometimes API Consumers may want to differentiate their own consumer "applications" that make calls to the same API. In this case, they use different API Key(s) for the same subscription, where each API Key is linked to its own "application". Effectively, an Application is just an alias for the relationship between Subscription and an API Key. Up to two alternative API Keys can be assigned to a single alias (Application). For example, a Developer Portal user registers two applications for the same Subscription, and naming these applications Order Web Portal and Order Processing Engine. These are two different registered applications, where each of them can call the same API Product via the same Subscription. Developer Portal user wants to differentiate (for example, for business analytical purpose) how his two different applications consume the same provider's API, so he creates two applications for the same subscription, and uses two different pairs of API Keys when calling API from his two applications. In this example, Order Web Portal and Order Processing Engine are just two aliases for different pairs of API Keys.