> ## Documentation Index
> Fetch the complete documentation index at: https://developer.hellgate.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Overview
> Link is a protocol-abstraction runtime: define an API contract once, bind it to any provider, and switch what's behind it without changing the caller.
Link is the **protocol-abstraction runtime** of the [Composable Payment Architecture](/platform/cpa). It sits between an API and whatever fulfils it: you define a versioned API contract — a **protocol** — and bind it to one or more real providers through declarative **backends**. Callers invoke the protocol; Link maps each request onto the configured backend, dispatches it, maps the response back, and logs the exchange.
The result is a clean split between the API a consumer codes against and the system that actually serves it. **Change what's behind the API without changing the API.**
## Role in the Hellgate Cloud Platform
Like every service on the platform, Link can be used standalone or in composition with others. Within the platform it is the **PSP and provider connectivity layer** — the component that [Specter](/products/specter/overview) reaches through to call external risk engines, and that [Commerce](/products/commerce/v2/overview) routes through to reach acquirers and payment service providers.
Where other services own a capability (Guardian owns tokenization, Specter owns decisioning), Link owns the *connection*: one runtime that decouples consumers from vendor wire formats so that integration becomes **configuration, not code**.
## Core concepts
A versioned, schema-validated API contract — the **actions** callers invoke (`assess`, `authorize`, `capture`, `refund`) and the shape of each request and response.
A binding from a protocol to a real provider — credentials, an authentication strategy, and the declarative **mapping rules** that translate the contract into that provider's wire format.
Calling a protocol action. Link selects a matching backend, runs the request mapping, dispatches the call, maps the response back, and writes an execution log.
## How it works
A request arrives against a protocol action. Link validates it against the action's schema, maps it onto the chosen backend with declarative rules, dispatches the HTTP call, maps the response back to the protocol's shape, and records an execution entry.
```mermaid theme={null}
sequenceDiagram
participant C as Caller
participant L as Link
participant P as Provider
C->>L: POST /api/invoke/{protocol}/{action}
Note over L: Validate · select backend · map request
L->>P: Provider-native request
P-->>L: Provider-native response
Note over L: Map response · write execution log
L-->>C: Protocol-shaped result
```
Because the contract and the provider are separate, you can point the same protocol at a different backend — or run several side by side — without the caller ever knowing.
## What you get by default
Every protocol inherits a shared operational surface, so each new integration starts with it rather than rebuilding it:
* **Declarative mapping** — adapter logic lives in versioned templates and a filter chain, not in per-vendor code or deploys.
* **Generated OpenAPI** — each imported protocol produces its own OpenAPI 3.1 specification.
* **Message-level encryption** — optional JWE encryption of request and response bodies, with rotatable keys, for providers that require it.
* **Credential and key rotation** — rotate backend credentials and encryption keys without downtime.
* **Execution audit log** — every invocation is recorded asynchronously with timing and the provider response.
* **Outbound safety** — backend hosts and imported protocol URLs are validated against an SSRF guard (HTTPS-only, no private or internal addresses) when you register or update them.
## Integration as leverage
The split between contract and provider is not just an architectural convenience — it is the point.
* **Front of house** — present the API a customer already uses. They re-point rather than re-build, so a migration becomes *your* configuration instead of *their* project.
* **Back of house** — bind that same API to any provider, and switch or combine providers, without the customer ever knowing.
This is how Hellgate runs its own platform: real volume flows through Link today, emulating the functionality that matters across very different backends behind single, stable contracts. For the commercial framing of this model, see the [Composable Payment Architecture](/platform/cpa) overview.
## Next steps
The Bundled and Standalone editions, tiers, and how to obtain a Link instance.
Import a protocol, register a backend, and invoke your first action end to end.