Permissions define which Payt resources your app can access and which actions can be performed on those resources. Permissions are implemented using OAuth2 scopes. The words permissions and scopes can be used interchangeably.
If your app performs an action on a resource it does not have permission for, a 403 forbidden response will be returned. The response message will include the name of the permission your app requires in order to perform the action.
Users can, at any moment, change the permissions they granted to your app. Your client should be able to handle 403 responses and inform users that a particular action cannot be performed until they enable the corresponding permission.
List all permissions
A list of all currently available permissions can be found on the application create/edit form.
View granted permissions
The permissions that are granted on a specific authorization are returned each time a new token is created or by sending an existing token to the introspect endpoint.
The response contains, among other data, a space separated list of all granted permissions.
Add permissions
Permissions can be added to an application using the edit form in the Payt interface.
This will have no direct impact on any existing authorizations. All current authorizations and tokens will remain valid, but will not include the new permission automatically. Users will have to explicitly grant this new requested permission through the Payt UI. Payt will not actively inform users about this change.
If you use the scope parameter in the authorize_url, remember to include this new scope in the parameters. Otherwise users will not be asked to grant them during the authorization process. If you do not supply the scope parameter, then no further action is required, as the authorization process will automatically include this new scope.
Remove a permission
An existing permission can be removed from an Application using the edit form in the Payt interface.
This scope is immediately removed from all existing authorizations and tokens. A 403 forbidden will be returned on all endpoints requiring this scope, even for previously created and still valid tokens. Users do not have to take any action and are not informed. If you re-add the same scope in the future, all users will have to grant the scope explicitly, even if they authorized it in the past.
If you use the scope parameter in the authorize_url, remember to remove this scope. Otherwise a 400 bad_request error will be raised during the authorization process. If you do not supply the scope parameter, no further action is required as the authorization process will automatically leave out any removed scope. Last modified on June 16, 2026
