Comment on page
API Monetization Workshop
This scenario is typically used in Revenium workshops to provide training to users on the major points of Revenium functionality.
Revenium gives you the capability to combine individual APIs into distinct bundles ("Products" in Revenium language) designed to be sold to a specific portion of your target market. Products in Revenium are first class citizens, in much the same way they would be in a Configure, Price Quote (CPQ) or Product Lifecycle Management (PLM) application.
A Product in Revenium can consist of one or more APIs. When Consumers request access & pay for access to a Product, they will receive a Product Licenses from Revenium that they can use to access any API associated with the Product.
All invoicing performed by Revenium occurs at the Product level with the ability to see individual bundled API usage as Line Items in that Invoice.
During the workshops we will use a fictional firm, Mythic Petroleum, to demonstrate the capabilities of Revenium.
Mythic Petroleum has been undergoing an organization-wide, API-first digital transformation initiative for the last two years. Mythic Petroleum’s Shared Platform Team has been successful in developing various APIs both for both internal use cases as well as for external partners.
Mythic Petroleum wants to take two widely used internal APIs and externally monetize them for their drilling partners. In this workshop we'll see how these APIs can be metered and monetized using the Revenium platform.
Also note that while this entire scenario demonstrates how products, assets, users, etc. can be created manually in the Revenium portal, we expect that most sophisticated use cases will automate all of these steps via Revenium's platform API. This scenario should provide a solid background in the key concepts used in Revenium's portal before any integration & automation work begins.
In this lab you will define a new Product. Products can consist of one or more APIs. In this workshop we will create a Product that consists of two APIs.
Mythic Petroleum has two Experience APIs that have been widely adopted internally. The APIs expose drilling hazard data to an iOS app installed on field team members’ iPads. Maeve, the Product Manager and API Owner of these APIs, has been asked to externally offer these APIs and monetize them as part of Mythic Petroleum digital product portfolio. Maeve needs to rationalize these offerings with her broader product portfolio represented in Salesforce CPQ and Propel PLM. This will allow Maeve to meter, quote, charge for and track the roadmap of the Hazard Data APIs like the rest of her product portfolio.
Navigate to the Manage → Products using the left navigation bar
Creating an API Product
Define the following fields for the Product
- Name: The Product’s name
- Version: The version number or name of the Product
- Publish to Commerce Portal: Whether or not the Product should be displayed on any integrated API / Developer Portals. This allows an API product manager to control which configured products are published dynamically in an integrated developer portal.
- Cost (Rate Charged / Subscription Fee): The Base Cost of the Product (note that the Base Cost can be varied dynamically using Pricing Rules)
- Pricing Model: The Product’s monetization mechanism. Can be one of the following values:
- Transactional: Charges are invoked per API invocation
- Subscription: A subscription renewal fee is charged at the beginning of a Settlement Period and includes a fixed number of transactions that cannot be exceeded.
- Subscription with Overage: A subscription renewal fee is charged at the beginning of a Settlement Period and includes a fixed number of transactions in the renewal fee. Additional transactions are charged at the overage rate defined in the plan after the subscription quota has been exceeded.
- Settlement Period
- The interval at which consumers of the Product are Invoiced for their usage of the Product’s API
Defining an API Product
In this screen you can associate existing Pricing Rules, Payment Configurations Assets and SLA Definitions to a Product. Since we haven’t created any of these yet, however, you can leave them blank and click on “Next”
Note that Revenium allows for automated payment collection via 3rd party payment providers (currently Stripe). Although this is not used in this lab, credit card collections can be configured by adding a "Payment Configuration" (explained here). This must be configured at a global level, as well as for each product for which you intend to collect payments via Stripe.
Leave these fields as their defaults, then click on "Next"
On the final screen you have the ability to configure a number of fields that are generally used in an integrated development portal. Populating these fields allow API Product Managers to configure the appearance & configuration of products in a linked developer portal all within Revenium's low-code platform.
Examples of the fields available for catalog configuration include associating the Product with an external marketing URL (i.e. to a non-developer focused marketing page providing more details on the offering), a link to a product's Terms and Conditions that must be accepted before purchasing a subscription, an ERP Product Code that allows revenue to be reported correctly when Revenium shares usage information with the linked ERP system, and configuration of notifications for Product Owners or sales teams when a certain percentage of an allowed quota is reached.) As configuring an integrated developer portal is beyond the scope of this workshop, for now we will leave these as their defaults and click on "Save"
Leave these fields as their defaults, then click on "Save"
Products consist of one or more Assets. Products are the abstraction that a Product Manager uses to build & sell a portfolio of Assets. Revenium allows you to meter API utilization and the API and API Resource (ie, URI and method) level of granularity. It is also possible to meter event driven and asynchronous APIs.
Maeve will now register the Hazard APIs in Revenium. This will enable her, in the next lab, to group the APIs as a Product that can be monetized.
In this Lab you will tag an existing API with the Revenium platform.
Navigate to the Manage → Assets tab and click on the “plus” icon
Defining an API Asset
Define the following fields for the Asset:
- Asset Name: The name of the Asset
- Asset Type: The type of the Asset
- URL: The URL of the API
- Version: The API’s version number or name
Defining an API Asset
Now we can associate the API with the Product we created previously. Select the Product from the drop-down list. You can leave the Owner and Organization set to their defaults.
Associating the API Asset with a Product
You should now see the newly created Asset
The newly created Asset
Let’s go ahead and quickly register another Asset. We will assign this Asset to the same Product - effectively enabling us to “bundle” the two APIs together.
Defining a second API Asset
Defining a second API Asset
Defining a second API Asset
In this lab we will create a consumer who will consume the API and be charged for the Product usage. The Product Consumer is generally an application developer who wants to use an API in their application. The Product Owner will generally register Product Consumers and create and share “Product Licenses with them.
Acme Drilling, Inc, one of Mythic Petroleum’s B2B partners, has agreed to be one of the first customers for Hazard Avoidance. Maeve needs to register them as a Product Consumer so she can issue a Product License based on the sales order coming in from the Account Team. Acme Drilling will be leveraging the Hazard Avoidance APIs as part of their mobile application.
First we will create an Organization for all Acme Drilling, Inc users:
Creating an Organization
Now that the Organization is created we can go ahead and add a User
Navigate to the Manage → Users tab and click on the “plus” icon:
Adding a User
Define the following for the User:
- Username: The user’s username Email Address:
- Email Address: The user’s email address
- Organizations: The organizations the user is a member of (you can leave this as the default for now)
- Roles: The roles associated with the user. This dictates the level of permissions they have in Revenium. Please select “API Consumer.” This role allows the consumption of APIs only, with no access to the Revenium portal. Additional roles are explained here in Revenium's RBAC documentation.
In order to monetize our API-driven Products, we need to track who is consuming our Products so we can meter and invoice their usage.
In this lab we will create a Product License that the API Consumer will use to access the API. The Product License is a string that an Application Developer will add to their application so their API usage can be metered. You will need to share the Product License with the developer after the steps in this section are completed.
Maeve can now create a Product License that the Acme Drilling’s developers can use to meter their mobile application’s usage of the Hazard Avoidance APIs. The Product License is unique and will be used by the mobile app developers to access all the APIs that comprise Maeve’s single Product.
Navigate to the Manage → Product Licenses tab and click on the “plus” icon:
Adding a Product License
Define the following to create a Product License
- Description: A description of the Product License
- Consuming Organization: The Organization the Product License belongs to. This field will be used in reporting revenue and usage by customer.
- Client Owner: The User to whom the Product License belongs. Set this to the API Consumer you created previously.
- Products: The Products this key grants entitlements to
We can set some additional parameters on the Product License. These include the following:
- Notification Addresses on Creation: The email address of someone who should receive a notification when the Product License in created (often an API product owner who wants to be aware when new customer integrations are created)
- Notification Addresses on Quota Threshold: Who should receive a notification when the Product License approach a Quota Threshold (if its configured on the Product)
- Quota Notification Threshold: The percentage of quota consumed before sending a Quota threshold warning
- Product License: Override the default behavior to create a GUID based Product License (this is useful for correlating the Product License with a key in another system, ie OAuth)
- Expiration Date: When, if ever, the Product License expires
- External Quote ID: Allows for correlation of the Product License with an external CPQ (Configure Pricing Quote) system. This is often useful for reporting purposes.
For the purposes of this workshop we can leave all fields to their defaults.
Creating a Product License
Click on "Save"
Creating a Product License
Revenium’s Dynamic Pricing Rules give API Product owners the ability to vary API pricing based on dynamic business conditions. Pricing Rules use a simple language that makes it easy for users to define rules that modify pricing based on the context of the API transaction.
The primary concept in Dynamic Pricing Rules is a “Line Item”. A Line Item represents an API transaction that has not been invoiced, allowing Revenium dynamically adjust the price based on the script.
A Line Item has the following fields associated with it:
The Hazard Avoidance APIs make extensive use of System APIs to source their data and can be sensitive to load. After talking to Central IT, Maeve wants to offer Acme an incentive to use the Hazard Avoidance APIs off hours as much as possible. She will author a Pricing Rule that computes a 20% discount for all API usage off hours.
To create a new Pricing Rule:
Navigate to the Manage → Pricing Rules tab and click on the “plus” icon
Creating a Pricing Rule
Now we can define the Pricing Rule's Name, Organization and Owner (you can leave all settings as their defaults for this exercise) We can also set the Default Execution Note. This will let consumers see what Pricing Rules were applied when they are invoiced for their API usage.
Creating a Pricing Rule
Now we are ready to define the Pricing Rule. We will author the Pricing Rule using the Revenium Scripting Language (HSL). The following rule will apply a 20% discount to off-hours API utilization:
Applying a 20% discount to off hours API utilization
We can click on "Test Rule" to simulate the rule execution to ensure it works properly:
Validating the Pricing Rule executes correctly
Finally we can save the Pricing Rule
Save the Pricing Rule
Note that we can also alter the test data for the rule:
Experimenting with Test Data
Now that the Pricing Rule is created you can associate it with a Product:
Associating a Pricing Rule with a Product
Now that an Product has been defined, API Assets have been associated with it, a Product License has been created an an optional Pricing Rule has been applied you can configure your API Gateway with the appropriate Revenium Metering Policy / Plugin to begin metering traffic.
The API Consumer can now modify their application to access and be charged for the API utilization. To do this the application developer must make sure the X-REVENIUM-PRODUCT-KEY header is set on all HTTP/HTTPS requests that their client application is making.
Now that the Hazard Avoidance APIs are being metered, Maeve can coordinate with Acme’s mobile architect to share the Product License ID. The architect, Nial, works with the iOS and Android developers to modify the HTTP requests in their applications to include the X-REVENIUM-PRODUCT-KEY header.
Note that alternatives authentication methods exist so that the user does not have to change the headers used to access Acme Drilling's APIs, though these are beyond the scope of this workshop.
The Product License for an API Consumer can be obtained from Revenium by navigating to the Manage → Product Licenses tab**:**
Copying the Product License
Once the application developer has modified the consuming application to pass the Product License in the X-REVENIUM-PRODUCT-KEY Revenium can begin metering requests. We can now explore the UI to see how to observe transactions, charges and reports.
You can simulate a transaction by running the following curl command:
curl -H "X-REVENIUM-PRODUCT-KEY: PRODUCT_KEY" http://PROXIEDAPI_URL/
Once Revenium begins metering API traffic you can navigate to the “Recent Transactions” menu item to see the most recent transactions rolled up as Line Items. For each Line Item you will see the following data:
- Timestamp: the time the transaction occurred
- Product: the name of the Product
- Product License: the Product License
- Asset: the API being consumed
- Application: the (optional) Application that is consuming the Asset [not used in this scenario]
- Pricing Model: the type of transaction (ie, transaction, subscription, etc)
- Call Count: the number of calls occurring within the Metering Period
- Charge: the amount to be charged when an Invoice is generated
- Log: list of any Pricing Rules executed as part of the charge calculation
Maeve can now begin to observe translations and charges incurred by Acme Drilling.
If we navigate to Transactions -> Recent Transactions we can view any settled Line Items that have been processed by Revenium:
Viewing Recent Transactions
Revenium provides executive level insights into API Monetization initiatives. These Dashboards make it easy to visualize and export KPIs and metrics on the value that APIs are delivering to the business.
Maeve, as well as her management, can begin gleaning insights on API Product usage across the firm. The CIO, Jane, is particularly excited about this as she is also the API Program Sponsor.
Revenue Reports give you visibility into the income generated by your monetized API Products.
Viewing a report on the revenue generated by monetized APIs
Product Requests lets you report on how Products are consumed.
Viewing a report on aPI Product consumption
The Product Consumers reports give you insight into who is consuming your API Products
Viewing the details of consumers for an API ProductWrapping Up
While outside the scope of this lab, this section provides a brief explanation of how invoicing and payment collection works if you wish to continue the exercise on your own.
Invoices are automatically generated in Revenium at the end of every product's settlement period (which is defined as daily, monthly, annually, etc. when first creating the product). They are sent to the person registered as the owner of the Product License and will contain a summary of the line items contributing to the total charges.
Revenium can support the following methods of invoicing & collection:
- 1.Revenium-generated Invoice + Stripe Payment Collection: Revenium automatically sends PDF invoices (which can be custom branded) to the owner of each Product License at the end of a settlement period. Additionally, Revenium uses your stripe API credentials (configured within Revenium), to collect the amounts due from each customer. Tax can be calculated automatically as well if you subscribe to the Stripe Tax service within your stripe account. Using this methodology, funds are collected & deposited directly by Stripe into your account.
- 2.Revenium-generated invoice with manual payment remittance: Revenium automatically sends PDF invoices (which can be custom branded) to the owner of each Product License at the end of a settlement period. The invoice template will contain remittance instructions for your customer to send payment to you via your normal accounts receivable process.
- 3.Revenium ERP integration for Customer-generated invoices: In this scenario, Revenium sends the required usage and cost information to you via an ERP integration that allows you to create invoices for your customer directly from your standard accounts payable systems. Please work with your Revenium account team to set up this type of integration if required.