Skip to main content

Secure API Request Signing and Idempotency Mechanism

Overview

๐Ÿงฉ This API leverages a robust security mechanism involving HMAC-based request signing, timestamping, unique request identification (nonce), and idempotency keys. These mechanisms collectively ensure the integrity, authenticity, and non-replayability of client requests, as well as safe handling of duplicate submissions. ๐Ÿ“˜ This documentation explains each mechanism, their purposes, and how to implement the required client logic (e.g., in Postman or custom API clients).

1. HMAC Signature (X-Signature Header)

What is it?

๐Ÿ”‘ An HMAC (Hash-based Message Authentication Code) is a cryptographic signature generated using a shared secret and the request data. It ensures that the request cannot be tampered with, and its sender can be authenticated.

Purpose

  • Integrity ๐Ÿ›ก๏ธ: Detects if any part of the request (method, URI, body, timestamp) has been altered.
  • Authentication ๐Ÿ”: Confirms the request is from a trusted client who knows the secret key.
  • Anti-Replay โ™ป๏ธ: Tied to a timestamp and unique values, making replay attacks detectable.

How is it used?

  • The client constructs a string to sign, concatenating the HTTP method, full request path (including query), current timestamp in epoch milliseconds, and resolved request body ๐Ÿงพ:
  • The client generates the HMAC SHA256 signature using the shared secret (kept in a secure vault, never exposed) ๐Ÿ”’:
  • This signature is sent in the request header X-Signature ๐Ÿš€.
โš ๏ธ Please ask us HMAC Secret before making your first API call.

What if not used?

  • Client will receive an error message with http status 400 - Bad Request

What if signature is not valid?

  • Client will receive an error message with http status 401 - Unauthorized

2. Timestamp (X-Timestamp Header)

What is it?

โฑ๏ธ The Unix timestamp (in milliseconds) at the moment the request is generated.

Purpose

  • Anti-Replay ๐Ÿ›‘: Prevents an attacker from reusing a previously valid request, since the server can enforce strict time windows for valid requests.

How is it used?

  • The client generates the timestamp just before sending the request and includes it as the X-Timestamp header โŒš.

What if not used?

  • Client will receive an error message with http status 400 - Bad Request

3. Nonce (X-Nonce Header)

What is it?

๐ŸŽฒ A nonce is a randomly generated unique identifier (UUID v4) included in each request.

Purpose

  • Anti-Replay ๐Ÿ”: Further prevents request replay by uniquely identifying each request. Even if method, URI, and body are the same, the nonce will differ.

How is it used?

  • The client generates a new UUID v4 for every request and includes it as the X-Nonce header ๐ŸŽฏ.

What if not used?

  • Client will receive an error message with http status 400 - Bad Request

What if re-used?

  • Client will receive an error message with http status 409 - Conflict

4. Idempotency Key (X-Idempotency-Key Header)

What is it?

๐Ÿชช A unique identifier (UUID v4) for each request, enabling the server to recognize and safely ignore duplicate submissions (e.g., from retrying a POST request).

Purpose

  • Idempotency ๐Ÿ”‚: Guarantees that retrying a request due to network errors will not result in duplicate resource creation or side effects.

How is it used?

  • The client generates a new UUID v4 for each operation and sends it as the X-Idempotency-Key header ๐Ÿ“ฎ.

What if not used?

  • Client will receive an error message with http status 400 - Bad Request

What if re-used?

  • Client will receive an error message with http status 409 - Conflict

Security Considerations

  • The secret used for HMAC must never be shared or exposed in client code or documentation ๐Ÿ”.
  • Always use HTTPS to prevent man-in-the-middle attacks ๐ŸŒ.
  • Servers enforce a maximum allowable time skew for the X-Timestamp and reject used/replayed X-Nonce or X-Idempotency-Key values within a certain window โ›”.

Example Headers

Summary Table ๐Ÿ“Š