How it works
- Every Specter instance comes with a bundled Link instance that serves its backends and scales with it — there is no separate Link contract to arrange.
- The Specter protocol is enabled on that instance and your chosen backends are configured.
- Specter registers the Link instance as an integration and discovers the backends it exposes.
- The discovered backends become available to your rulesets automatically.
The bundled Link instance is locked to serving your Specter backends. To run other protocols or send other load
through it, unlock it into a Standalone instance — see
Link Plans & Access.
Available backends
The catalogue of backends grows continuously — for example VISA Decision Manager, Ravelin, Worldpay FraudSight, and Featurespace. Contact your account representative for the current list and help choosing the right backend for your requirements.Context validation and fail-open
Before calling a backend, Specter validates that the decision context contains the fields the backend requires. If a required field is missing, no call is made: thebackend_results entry records an insufficient_context
error so you know exactly what to add.
Backend rules also carry an on_error setting (allow, block, or review) that governs what happens when a
backend errors or times out — allow skips the backend so an infrastructure failure never blocks a customer.
Composing backends
A single backend rule calls one backend. A backend group rule orchestrates several — the foundation for migrating from one backend to another, A/B testing, and high-availability setups. A group runs its members with one of three strategies:| Strategy | Behavior |
|---|---|
fallback | Try members in order; use the first live member that returns a result. If one errors or lacks context, try the next. |
parallel | Call all members at once and combine their outcomes with a merge strategy. |
split | Route each request to exactly one member, chosen by weighted random distribution. |
parallel group, the merge strategy decides the combined outcome:
| Merge | Outcome |
|---|---|
strictest | The most severe outcome wins (BLOCK > REVIEW > ALLOW). |
most_lenient | The least severe outcome wins. |
consensus | The shared outcome if all members agree, otherwise REVIEW. |
Shadow members
A group member can run in shadow mode (live: false): it executes and its result is recorded in
backend_results, but it does not contribute to the decision. Shadow members let you trial a new backend
against live traffic before trusting it. (In a split, the selected member always runs live.)
Asynchronous groups
A backend group can run asynchronously (async: true). Specter returns a PROVISIONAL decision from the
local rules immediately and evaluates the group in the background, delivering the final outcome by webhook — see
Asynchronous decision with delayed capture.
Configuration
Backends are reached through integrations — connections to your Link instance, managed through the Admin API (scopesadmin:integrations:read / admin:integrations:write). A single integration can expose several
backends, and each backend rule selects one to invoke.
Configure a backend integration
Register a Link instance and discover its backends in the API reference.