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 vs. 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 ...").
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 execution 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 login 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 leads to non-intuitive behavior: a candidate from a high-priority API can intercept a call even though all its assigned association criteria are not applicable in the call context. The platform then returns HTTP error 403 Error: Forbidden. A lower-priority competitor without bindings to association criteria would have qualified as the recipient.
Special case: no assignment = no access restriction
WARNING
For APIs, endpoints, and tools: no assignment equals no access restriction.
Configurations that accept Association criteria are typically inoperable as long as no criteria are assigned.
For API configurations, the opposite applies: as long as you do not assign any Association criteria at a given level (API or endpoint/tool), access is unrestricted.
This has two consequences:
API configurations created before access control was introduced remain accessible without explicit assignments.
Removing all assignments from an API configuration lifts the access protection for the endpoints it contains.