Some data from your API might not be used or transmitted depending on local regulations, practice or formatting requirements from your customers. For instance, with GDPR personal data cannot be transmitted without consent. CCPA will be soon implemented in California (US). In addition, some recent scandals with Cambridge Analytica, Google +, T-Mobile show that the most capital-intensive companies have issues to be sure that their APIs will not leak information, they will be used as intended and data will be used as per licensing contract. Indeed, we often view APIs in terms of developer experience and how the average developer is going to experience the API product. API providers consider the API as it’s intended on being used. However, that’s not always the way the API interaction is going to be, of course and in faulty user experiences, the API might operate in unexpected ways. In the case of reverse engineering, that’s exactly what the hacker is trying to do. They try to call the API in a reverse manner to discover weaknesses in the API that might otherwise be obscured during normal use.
You have three main types of problem that you need to face with your APIs. Change of regulation, Misuse of data not aligned with licensing terms and hacking of your APIs. In other terms, you cannot plan your API once and for all for the future. When it happens, API providers so far simply cancel access to the existing API and release access to a new API with modifications needed. It requires engineering work to develop the new API and quite often changes backlog priorities for building key features of your products. That’s what Facebook did with the Cambridge Analytica scandal, and it is ok when you are Facebook as you know developers have no alternative data than Facebook for their apps. It disrupts your users’ own applications and developers/companies relying on your API are going to be angry about this and will certainly choose an alternative.
We built the solution for API product managers/owners so they can independently create API subsets of the API that we call API products. They have the full flexibility to define those API products and modify them overtime through a graphical interface determining which endpoints, data fields, data values, data result should be included or modified. They can define what is the intended way of using the API so if the API is not used as intended all data is simply filtered out. The use of the API is locked as it is intended.
However, API product managers/owners can evolve their API products overtime enabling them to change or modify API endpoints overtime without involving engineering.