Skip to main content
If you want to allow endpoints or features to have access from anonymous users. You will need to configure the access for them. Anonymous access is stored per application as a set of grants: the features a visitor can open without logging in, and the entity (table) operations a visitor can execute. Both are kept together with the rest of the authorization configuration.
Anything granted here is reachable without a user session, and it does not depend on the PERMISSIONS_ENFORCEMENT_ENABLED setting, which only governs the permission check for already authenticated users. Grant the narrowest set of operations your public flow actually needs. Changes can take a few minutes to propagate to every running instance of the application.

​
Where to configure it

Go to Application Designer → Authorization tab → Anonymous Access. That tab also holds Users, Roles, User Settings and the entity permissions granted per role, so the whole access configuration of the application lives in one place.

​
Anonymous access for an endpoint (table)

  1. In the Entity access panel, pick the table in the Entity dropdown.
  2. Check the actions you want to open: Read, Create, Update, Delete, Custom.
  3. Press Grant (or Revoke to take them back).
Each action maps to the endpoints generated for that table. For example, on Usuario:
  • Read opens Usuario, Usuarios and UsuariosAndCount.
  • Create opens createUsuario.
Internally each action is stored as an <action>:entity:<Table> claim on the application’s anonymous document — the same claim format used for roles.

​
Anonymous access for a feature

The Public features panel lists the features that can be opened without logging in, and links to each one so you can review what it exposes. Opening or closing a feature for anonymous visitors is applied through the grantAnonymousAccessToFeature operation, which stores the feature’s readable id on the application’s anonymous configuration.
Giving a feature anonymous access is not enough on its own: you also need to open the endpoints the feature uses. For instance, a public “create user” feature also needs anonymous access to the Usuario endpoints it calls.

​
About older applications

Applications configured before this model used a separate EntityPermissions collection. Those records are still honoured by the backend, and you can review them in the Backend Permissions (EntityPermissions) section of the same tab, but they are read-only: new grants are always written as claims on roles or on the anonymous document.