Authentication

Every request to A8 Core™ is signed. Signing proves who is calling and that the bytes were not altered in flight — it does not encrypt them, so all traffic also travels over TLS.

The model

A8 Core™ authenticates requests with HMAC-SHA256 over a canonical signing base. Your key id identifies which signing secret to use; the signature proves the request came from you and arrived intact. You pass the result in the Authorization header as HMAC keyId:signature:timestamp. Because a signature authenticates rather than encrypts, you always call over HTTPS.

Build the signing base

Concatenate the HTTP method, the request URL, the timestamp, and the raw JSON body, each on its own line. Compute the base identically on both sides and the HMAC will match.

POST
https://api.a8core.io/v1/accounts
1782925451
{"type":"individual","currency":"USD"}

Authorization: HMAC key_live_8fa2c1e4:9Hf2...Qe1c:1782925451

The 2026 profile — RFC 9421

A8 Core™ also offers RFC 9421 HTTP Message Signatures as a negotiable profile that runs alongside the baseline. It covers named components with a content-digest of the body and is the same signature format A8 Core™ uses on outbound webhook deliveries, so adopting it is a configuration change rather than a rewrite.

"@method": POST
"@path": /v1/accounts
"content-digest": sha-256=:X48E9qO...:
"@signature-params": ("@method" "@path" "content-digest");created=1782925451;keyid="a8core-prod-2026a";alg="hmac-sha256"

Signature-Input: sig1=("@method" "@path" "content-digest");created=1782925451;keyid="a8core-prod-2026a";alg="hmac-sha256"
Signature: sig1=:9Hf2...Qe1c:

Key rotation

Keys are identified by keyid, so you can rotate without downtime: we issue the new key, you start signing with it, and the old key stays valid through a short overlap before it is retired. Always send the keyid you signed with — never assume a single static key.

Provider isolation

Your credentials scope every request to your provider. There is no cross-provider data access: a key can only read and write the clients, accounts, and transactions that belong to it. This isolation is enforced on every call, not just at login.

Common errors

Best practices

• Compare signatures in constant time to avoid timing leaks.
• Sign on the server; never ship the secret to a browser or mobile client.
• Keep client clocks in sync — the created window is your replay defense.
• Log the RequestId from each response so failures are traceable end to end.

Where to next