HMAC, nonce and idempotency between services
HMAC · Nonce · Idempotency · Service API
How a website and microservice exchange financial commands safely
When wallet logic is isolated in a microservice, its REST API becomes the trust boundary. A static API key alone cannot prove that the request was not changed or replayed.
The solution signs a canonical representation of every request and treats replay prevention and business idempotency as separate controls.
Sign the request, not only a header
The canonical string contains the HTTP method, path, query string, SHA-256 body hash, timestamp, nonce and idempotency key in a fixed order. HMAC-SHA256 signs that string with a secret shared only by the two services.
Integrity
Changing the route, parameters, body or timestamp produces a different signature and the request is rejected before business logic.
Canonicalization
Both sides use exactly the same encoding, query ordering, body bytes and newline rules.
Secret handling
The secret is never transmitted and can be rotated through an explicit key identifier and transition window.
Timestamp and nonce prevent replay
Timestamp window
Requests outside a short accepted clock window are rejected even if their signature was once valid.
One-time nonce
A nonce is stored atomically for the window; seeing it again means the request is a replay.
Clock monitoring
Service clocks and rejection metrics are monitored so infrastructure drift does not silently block valid traffic.
Idempotency solves a different problem
A retry may be legitimate after a timeout. The idempotency key maps repeated attempts of the same business command to one stored result, while nonce values remain unique for each HTTP attempt.
Same command, same result
A duplicate withdrawal or balance operation returns the original response instead of executing again.
Payload binding
Reusing a key with a different request hash is rejected as a conflict.
Layered controls
IP allowlists, TLS, strict error codes and audit logs complement—not replace—request signing.
Technology and delivery
Expected result
A service API that detects modified and replayed requests while allowing safe retries without repeating a financial operation.
HMAC · SHA-256 · Timestamp · Nonce · Idempotency-Key · Replay Protection · API Security
Discuss your project
If you have a project involving Python, Laravel, Node.js, CRM, Telegram, AI/RAG, API integrations, automation or TON/GRAM logic, send me a short description of what you need.
You can simply explain what exists now, what is not working, what outcome you expect and which services are already involved.