Search
⌃K

Key Concepts & Relationships

This section provides a summary of the key objects used within HyperCurrent and the relationships between one another. These are the key objects & relationships required to monetize an API catalog.

HyperCurrent Objects

  • Assets - most commonly APIs, though they can also be API Resources (including a specific verb to be checked), connectors, or streams. Assets are expected to be bundled into products.
    • Assets are synchronized between HyperCurrent and API Gateways using a unique identifier from HyperCurrent known as an Asset ID. This Asset ID is configured as a part of the gateway policy as well as the HyperCurrent user interface.
  • Products - Products are bundles of Assets that are sold as a package to customers. Products have associated subscription terms and fees, overage rates, quotas, SLAs, and more attached to them.
  • Product Keys - issued to each of your end users to allow them to access your products (and their associated assets). These keys allow HyperCurrent to track usage by each customer individually.
  • Applications - allow metering of customer usage without requiring your customer to use HyperCurrent issued product keys. Applications in HyperCurrent contain two key pieces of information that allow them to form a link between gateway client IDs and HyperCurrent product keys. "HyperCurrent Applications are assigned an external ID that matches a gateway or IDP issued Client ID (generally associated with an OAuth Application), and are associated with one or more product keys in HyperCurrent to form this connection. Once an application has been created with the required information, HyperCurrent can meter end user transactions without the use of HyperCurrent provided product keys.
  • Users - Users are the owners of various objects in HyperCurrent. Most importantly for this example, users are the owners of product keys, which creates the entitlements for a single user to a Product.

Relationships Between Objects

Relationships between gateway & HyperCurrent components: assets, products, and applications.
  • Products typically are associated with numerous assets (APIs).
    • Products are also associated with numerous product keys (one per subscriber who has purchased access to the Product)
  • Product Keys can be associated with multiple HyperCurrent Applications. Using this approach, if a single subscriber has multiple applications, they all can be associated with a single product key which will meter all activity for the subscriber under the same subscription regardless of which application is used.
  • Users - Every product key and application can have only one User owner. This is the owner of the subscription.

Example Scenario

A healthcare company ("Pharma House") is publishing a product for prescription drug research. Their product is "Platinum Unlimited: Pharma Research" and includes access to 5 APIs that perform different functions required to conduct research. These APIs need to be accessed by 2 customers. Customer 1 has 5 different gateway-provided applications accessing the product, and Customer 2 has only a single application. The setup in HyperCurrent would appear as follows:

Corresponding Configuration in HyperCurrent & the API Gateway

  • User(s): One user is created each for the end user at Customer 1 and Customer 2.
  • Asset(s): Each of the five assets would be created to correspond with its API. As a part of asset creation in HyperCurrent, unique identifiers for each would be created by HyperCurrent.
    • These unique identifiers would then be configured in the gateway policy as well (note: options exist to automate this synchronization, but are beyond the scope of this simple tutorial).
  • Product(s): A single product ("Platinum Unlimited") would be built in HyperCurrent and associated with the 5 assets that make up this product bundle.
  • Product Key(s): Two product keys are required, one for each user subscribed to the "Platinum Unlimited Product".
  • Application(s): "Pharma House" does not want its customers to have to use HyperCurrent product keys, so it creates a HyperCurrent Application to link each gateway-provided ClientID to a HyperCurrent product key (and subsequently, the user/owner of each product key).
    • Customer 1: Pharma House creates five HyperCurrent Applications (one for each clientID in the gateway) and associates Customer 1's productKey to all five Applications.
    • Customer 2: Pharma House creates a single Application for Customer 2 and associates their product key with that Application.
Using this configuration, each customer can access the "Platinum Unlimited" product with no change to how they are sending API calls, and HyperCurrent will meter and rate each subscription accordingly.
Last modified 30d ago
© HyperCurrent - www.hypercurrent.io