TrustBridge

Sign from your own application,
without moving a private key.

TrustBridge is a REST implementation of the SignSession Contract: your application presents an API key, opens a Signing Session bound to a CPF, and posts documents to it. The certificate is read where it already lives — on the holder's workstation, or in the Server's own vault — and the private key never sees more than a hash.

The key only ever sees a hash

A1 and A3 certificates are read where they live, by a service on the workstation itself; a Vault Certificate is opened inside the Server. Either way what reaches the key is a hash and what comes back is a signature, so no exportable key material crosses the network.

The holder authorises every session

Opening a session takes a PIN. For a certificate on a workstation it is compared against the PIN entered at that machine's own console and never presented to the token, so a wrong value cannot burn a retry counter. The session it opens is bound to one holder and one certificate, and expires on its own when the signing stops.

One Server, inside your own network

A single container against your own SQL Server. The versioned contract, the admin console, the workstation channel and the published API document are served from the same host on the same port, and the Audit Log stays somewhere you can query it.

Built to be called by your applications

An integration is a registered Client Application and the API keys issued to it — there is no SDK to link against and nothing to install on the machine your code runs on. The surface is a versioned REST contract, published by the deployment itself as an OpenAPI 3.1 document, and it has another implementation: an application already written against that contract integrates here, with the differences written down rather than discovered.

Everything an integration calls:

X-API-Key: <api-key> POST /v1/sessions → sessionId POST /v1/signatures → signatureId POST /v1/signatures/batch → signatureId[] GET /v1/signatures/{signatureId}/document → 200 application/pdf

Transport

HTTPS · application/json · multipart/form-data

Authentication

X-API-Key

Contract

OpenAPI 3.1 · /v1

Refusals

{ "error": { "code", "message", "details" } }

What the platform puts on screen

Your application never draws a signing screen. The admin console is where an operator watches sessions, keys and the Audit Log; the Tray App is where a holder types a PIN, on their own workstation and nowhere else.

The admin console. Every Signing Session on the deployment, the certificate and workstation each one is bound to, and the trail behind it.