APIs let you grant read or write access to content managed on the Lobster Data Platform. You can also use APIs to drive workflows. These workflows often connect third-party systems through an integration.
Security is part of every API plan. This applies to every use case and every type of interface, for example REST API and MCP Server.
Access control for endpoints of a REST API or for tools of an MCP Server checks four levels:
URL access to the platform
Activation status of the API configuration
Authentication requirement per endpoint or tool
Optional: assigning Association criteria
URL access to the platform
The first control level checks whether the Lobster Data Platform is reachable by URL. Start with one question: who can reach the platform by URL at all?
Activation status of the API configuration
An API must be active (enabled). If it isn't, none of its endpoint or tool configurations work.
If there's no active API with a matching definition for the endpoint or tool, the platform responds with the HTTP error 404: Not found.
For details on activating an API configuration, see API Manager.
Authentication requirement per endpoint or tool
Each endpoint or tool definition has the Anonymous access flag. It determines whether unauthenticated access is possible:
true: anonymous access permittedfalse: only authenticated access permitted
In the code, this flag is named allowAnonymousAccess. The UI label and the code name refer to the same field.
If the Anonymous access flag is set to false and the request is still anonymous, the platform responds with the HTTP error 401 Error: Unauthorized. The response body then returns the Lobster Data Platform error code CORESYSTEM_AuthenticationManager_401.
Security risk of anonymous access
Before you allow anonymous access, check carefully how secure the underlying action is.
CAUTION: Anonymous calls have no session context.
A workaround using Run as can compensate for this. If the underlying action uses a role without ownership restrictions, for example Superuser, the anonymous endpoint can expose sensitive data without protection.
Never test anonymous access in a browser window where you're already signed in to the Lobster Data Platform. The session cookie applies there automatically and skews the test. Use a private window or a separate REST client instead.
Optional: assigning association criteria
You can also bind access to an API, an endpoint, or a tool to Association criteria. This lets you define arbitrarily complex validation criteria.
The validation logic evaluates any Rule types.
Rule types for authenticated access
For authenticated access, the following rule types from the Session based category are particularly relevant:
Special case: anonymous access
Anonymous access has no session context. There is no Company of session as a reference point. This also means there is no basis for ownership restrictions or Company authorizations.
As a result, association criteria apply to anonymous access only if they have no owner assigned. This is always true for system-predefined association criteria ("Assign to …").
Precedence of endpoint and API level
You can assign association criteria on two levels: the API level or the level of the individual endpoint or tool.
The platform evaluates only one level per call. If an endpoint or a tool has its own association criteria, the platform evaluates only those. The criteria on the API level are then ignored.
Without association criteria on the endpoint or tool level, the API level applies instead.
Behavior with multiple assigned criteria
If you assign multiple Association criteria in parallel, at least one must be met. Only then is the configuration considered "associated in context".
Access to REST API endpoints or MCP server tools is restricted by assignments only when all assigned criteria fall into one of these states:
Not met: the criterion failed in the call context.
Not relevant: ownership restrictions in the call context exclude the criterion.
In both cases, the platform responds with the HTTP error 403 Error: Forbidden. The request reached the API, but processing was denied. The response body returns the Lobster Data Platform error code CORESYSTEM_AuthenticationManager_403.
The error message for this code reads "Invalid login info". This lacks precision. The error also occurs for a valid, even anonymous, call when the assigned association criteria don't apply. It doesn't necessarily mean the credentials are wrong.
Selecting between competing endpoint/tool definitions
Technically, different API configurations can provide definitions for the same effective endpoint or tool address. If multiple candidates qualify as the destination at runtime, the platform evaluates them hierarchically.
Step 1: HTTP method match
For a REST API call, the HTTP method must match the endpoint configuration.
If none of the candidates meet this criterion, the platform responds with the HTTP error 405: Method not allowed. The platform doesn't evaluate any further criteria.
Step 2: Anonymous call
If the call is anonymous, that is, without a session context, only candidates that allow anonymous access qualify. See the section Authentication requirement per endpoint or tool above.
Step 3: API configuration priority
If multiple candidates meet the relevant conditions, the priority of the parent API configuration decides. For details, see API Manager.
Step 4: Association criteria are evaluated later
The assignment of Association criteria does not affect selection. The platform evaluates association criteria only after it has chosen a candidate.
This behavior is not obvious. A candidate from a high-priority API can intercept a call, even when its assigned association criteria are not applicable in the call context. The platform then returns the HTTP error 403 Error: Forbidden. A lower-priority competitor without association criteria would otherwise have served the request.
Special case: no assignment = no access restriction
WARNING: For APIs, endpoints, and tools: no assignment = no access restriction.
Some configurations accept Association criteria. Such configurations typically don't work as long as no criteria are assigned.
For API configurations, the opposite applies. A level without assigned Association criteria grants unrestricted access. This applies to the API level and to the endpoint or tool level.
This has two consequences:
API configurations created before access control was introduced remain accessible without explicit assignments.
Removing all assignments on the API level lifts protection only for endpoints without their own association criteria. Endpoints with their own association criteria remain protected.