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 can include connected third-party systems through integration.
Security must be part of every API design. This applies regardless of the interface's purpose and characteristics (for example, REST API or MCP Server).
Access control for endpoints of a REST API or for tools of an MCP Server operates on 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 is URL reachability of the Lobster Data Platform. Start with one question: who can address the platform via its URL?
Activation status of the API configuration
An API must be active (enabled). Otherwise, all endpoint and tool configurations it contains are categorically ineffective.
If no active API contains a matching definition for the addressed endpoint or tool, the platform responds with 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 carries the Anonymous access flag (code identifier: allowAnonymousAccess). This flag determines whether unauthenticated access is allowed:
true: anonymous access permittedfalse: only authenticated access permitted
If an anonymous request fails the Anonymous access check, the platform responds with HTTP error 401 Error: Unauthorized. The response body then returns the Lobster Data Platform error code CORESYSTEM_AuthenticationManager_401.
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 can evaluate 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 are context-relevant for anonymous access only if they have no owner assigned. The same generally applies to system-predefined assignment criteria (“Assign to ...”).
Precedence of endpoint and API level
You can assign association criteria on two levels. The first level is the API. The second level is 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.
The API level applies only when no association criteria exist on the endpoint or tool level.
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 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.
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 HTTP error 405: Method not allowed. No further criteria are evaluated.
Step 2: Anonymous call
If the call is anonymous (without a session context), only candidates that allow anonymous access qualify. See the section “Authentication requirement per endpoint or tool”.
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. This happens 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 have qualified as the recipient.
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 are typically inoperable 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.