We are proud to say that we use our own API ourselves. All new REX application in the RamBase client are retrieving data from the same RamBase API as we make available for our customers and external developers. This means that everything you can see and do in the REX applications in RamBase can also be done though the API.
This also means that we are working continuously to update and create new APIs, and the available APIs is automatically updated in the documentation you find here.
To be able to make great REX applications in the RamBase client, we needed some framework APIs. These framework APIs is of course also available for you to explore and use, and we look forward to seeing the powerful integrations you create.
One REX application might contain several REX components, and one REX component can make several API requests to retrieve data to display. You can read more about REX applications in our developer guide. In addition to avoid duplicate requests from the different REX components, we also make batch requests to combine several API requests into one single request to avoid unnecessary performance loss of making too many requests.
Metadata requests provide metadata information about the API resources themselves. In the RamBase client this kind of metadata is used a lot. Good examples are validating input before making PUT/POST requests, presenting tooltip with description of each field, showing field suggestions for sorting and for filtering, both filter fields and named filters.
In the RamBase client input fields are also disabled if field cannot be updated, with a tooltip of why the field cannot be updated.
Check access requests
In the RamBase client we are using check access requests to hide context menu items which are not available. Context menu items are the menu shown in the upper right corner, showing different actions to perform in the application you are using.
In the menu item called "Unavailable menu items" you can find API operations that cannot be requested, including an explanation of why.
Current session requests
To know who is logged in to the API we make a current session request by using the access token to find out which user, system, customer/supplier this session belongs to.
ID verification requests
ID verification requests was not created for us, but for customers and external developers with the need of verifying users based on our authentication. Combined with current session requests this ID verification is a powerful tool to make great integrations using the RamBase API, without needing to implement user management and safe authentication.