...
An API resource represent either an API as a whole or a function within such an API. How you structure those is entirely up to you. You could create an API resource webshopadmin which gives the client full permission to an webshop API or you could further structure it down an create sperate API resources for things like webshop.readproduct and webshop.placeorder. You can further bundle them into API scopes and achieve the exact same behaviour.
...
An API resource consists of the following data.
Name | Datatype | Mandatory | Example | Description |
|---|---|---|---|---|
Name | String | ✅ | WEBSHOP_ORDER_API | The name of the API resource as it will be stored in the system. |
Description | String | The ordering API of the webshop | Used to display on the consent screen | |
Description name key | String | Customer.BestRun.ApiResource.OrderApi | Key to translate the name into multiple languages | |
Display name | String | Webshop Ordering API | The readable name of the name | |
Display name key | String | Customer.BestRun.ApiResource.OrderApiDescription | Key to translate the description into multiple languages | |
Show on consent screen | Checkbox | true | Whether or not this API resource needs to be displayed on the consent screen. You can disable technical scopes here if you want. | |
Order | Integer | 2 | The order on the consent screen | |
Application | Drop Down | ✅ | Webshop | The application the API resource belongs to |
Secret | Password | 🔑 * * * * * * * * * | The API secret that can be used by the API to authenticate at the |
https://itsense.atlassian.net/wiki/spaces/IKB/pages/1993736206/Endpoints#Introspection-Endpoint . |