How to authenticate every call to the Consent API — mutual TLS plus a sender-constrained bearer token.

Authentication

Every request to the Consent API is authenticated two ways at once:

Mutual TLS — you present your registered client certificate on the connection. See Set up mTLS.
A bearer token — a sender-constrained access token from the consent authorisation flow, sent in the Authorization header.

The token is bound to your client certificate (the cnf x5t#S256 claim), so the same certificate must be used on the connection that carries the token.

curl --cert client.crt --key client.key \
  https://api.provider.fiskil.com/consents \
  -H "Authorization: Bearer eyJhbGciOiJFUzI1NiIsInR5cCI6ImF0K2p3dCJ9..." \
  -H "x-fapi-interaction-id: 4f3d2c1b-0a9e-8d7c-6b5a-4938271605fe"

Include a unique x-fapi-interaction-id (a UUID) on every request and log it — Protección echoes it back, and it's how a call is traced end to end for support.

Base URL

Instance	Base URL
Production	`https://api.provider.fiskil.com`
Staging	`https://api.provider.staging.fiskil.com`

Errors

Errors return a JSON body with a machine-readable code and a human-readable message:

{ "code": "consent_not_found", "message": "No consent with that id exists." }

See Requesting Data for the full status-code reference, including the X-Sharing-Refused header.

The endpoints below are generated from the Consent API's OpenAPI definition, complete with a live playground — requests are sent to the base URL above.