1 minute read

Having successfully launched first monetisable API for my company, there’s a stream of feedback coming in, on how to improve

  • on-boarding experience
  • product documentation
  • product performance
  • rate plans

That last point rate plans kicked off an interesting debate and a sort of self investigation on the implementation of the monetisation module.

From API to API Products to Packages, association to the service provided by the API, creating rate cards and linking to rate plans. There are some significant challenges here in unlocking the power of this complex structure.

Key thing is; APIs provide access to a service, which we call an API product. Access to this service enables automates experience creation, access to remote information, communication channels, security enhancements like TFA & OTP. When we talk about API monetisation, it is about creating a mechanism to be able to charge for access to these services and not how many times or at what frequency an API is invoked.

This key element is missing from some monetisation module implementations and that forces developers to implement hacks, resulting in code bloats, even with help of an efficient devOps. Over a period of time these code bloats increase implementation times and Time to Market for new features.

Product managers and developers need to understand clearly how monetisation modules work till module developers can enhance their product capability to enable service charging instead of API charging.

Updated: