Skip to main content
Invocation is calling a protocol action. Link validates the request, selects a matching backend, runs the request mapping, dispatches the provider call, maps the response back to the protocol’s shape, and records an execution.
{protocol} is the protocol’s local ID and {action} is the action name. The call requires the invoke:execute scope.

​
The flow

  1. Validate the request against the action’s schema.
  2. Resolve the variant from the discriminator field, if the action is polymorphic.
  3. Select the backend that implements the action and variant.
  4. Map and dispatch the request to the provider.
  5. Map the response back to the protocol shape and log the execution.

​
Method matching

The HTTP method you invoke with must match the method the action declares in the protocol. A mismatch returns 405 METHOD_NOT_ALLOWED — it is not routed to a different action.

​
Selecting a backend

If exactly one enabled backend implements the action and variant, Link uses it. If several match, Link returns 409 CONFLICT; disambiguate with the backend query parameter:

​
Results

A successful invocation returns the protocol-shaped result. Its shape is defined entirely by the protocol — for the specter-v1 assess action, that is an enum outcome:
Two response headers accompany every result:
  • x-link-execution — the execution ID; use it to fetch the audit entry.
  • server-timing — total and external-call timing, in milliseconds.

​
Mapping errors

When the provider call completes but mapping cannot produce a valid result, Link returns a protocol error result rather than failing silently. The source field tells you where it originated:
source tells you where the error originated: backend (the provider returned an error you mapped through), mapping (a required leaf could not resolve), transport (the provider was unreachable or timed out), encryption (message-level encryption failed), or mock (a configured mock returned an error). Transport and encryption failures carry HTTP 502; the rest use the status from the response mapping. When a response mapping produces an error result, Link masks card numbers and sensitive authentication data (values under keys such as cvv or security_code) in it before it returns the result and records the execution. A provider that echoes the card number in its error message reaches the caller in masked form, in message and code alike. Error results without card data, and results of any other type, are returned exactly as mapped.

​
Error codes

​
Execution log

Every invocation — success or failure — is logged asynchronously. Fetch an entry by ID with the admin:executions:read scope:
The entry contains the mapped protocol result, the raw provider response, timing, the backend that handled the call, and any error detail — so you can verify a round trip without provider-side tooling.

​
Retention

Your instance configures a retention window, in days, for the execution log; the default is 30 days. Once the window has passed, the entry is deleted in full — mapped result, raw provider response, timing, and error detail alike — and fetching it returns 404 NOT_FOUND. Unlike a Specter decision, nothing of an expired execution survives, so export entries you need for long-term audit before the window closes.

​
Next steps

Backends

Configure the mapping that shapes each request and response.

Quickstart

Run the full flow end to end.