secp256k1 private key held by you. Static credentials, once leaked, give an attacker unlimited time; a signature, once leaked, is worthless — it is bound to one request, one moment, one body.
What protects your account
Asymmetric cryptography
BlooBank verifies signatures with your public key. Your private key never leaves your environment. There is no shared secret that both sides hold.
Replay protection
Every request carries a unique
X-Access-Request-Id deduplicated for 1 hour. Captured signatures cannot be replayed.Clock-skew enforcement
Timestamps outside ±10 seconds are rejected. A captured request has a 10-second window — by then, the request id has expired.
TLS-only
Every endpoint is HTTPS. TLS 1.2 minimum. Headers, bodies, and signatures all travel encrypted.
How it works at a glance
Even if an attacker intercepts a request mid-flight, they cannot mint a new signature without your private key. The key stays on your infrastructure; only signatures cross the wire.Your security obligations
You hold the private key. That carries responsibility.Never expose the private key
Isolate environments
Use distinct keypairs for sandbox, staging, and production. Never reuse a staging key in production. A breach in one environment must not cascade to others.Synchronize clocks
The ±10-second skew tolerance is tighter than typical cloud SDKs (which allow minutes). Every host that signs requests must run NTP:
VMs that pause and resume can have their clocks jump. Verify clock-drift correction on resume.
Rotate credentials periodically
Every 6–12 months, or immediately on suspicion of compromise:1
Generate a new keypair on the same environment
See Generate your keys.
2
Register the new public key
Send to your BlooBank integration contact. You will receive a new Access Key.
3
Cut over traffic
Switch your application to the new credential. Verify all production paths.
4
Revoke the old credential
Request revocation from BlooBank account team. After this, the old key is permanently invalid.
Log diagnostics, not secrets
For every non-2xx response, log:Verify webhooks before acting
Webhook deliveries are server-pushed and must be verified before processing — see Verifying signatures. An unverified webhook is an attack surface.Environments
Access credentials and signing keys are tied to the environment in which they were issued. Before going live in production:- Validate all integration flows in sandbox/staging.
- Verify authentication, request signing, response handling, and error handling are correct.
- Confirm webhook signature verification works end-to-end.
- Run load tests at expected peak traffic.
- Verify clock sync on all hosts that will sign requests.
When something goes wrong
Next
Authentication
The Access Protocol in detail.
Webhook signature verification
How to verify server-pushed deliveries.
Errors
What to do when something fails.