Skip to main content

Signature Format

name.com webhooks include an X-NAMECOM-SIGNATURE header containing the HMAC signature with additional security measures. The header value format is:
Where:
  • algorithmName=encodedSignature is the HMAC signature (e.g., “sha256=a1b2c3d4…”)
  • timestamp is the Unix timestamp when the signature was generated
  • nonce is a unique identifier (UUID) to prevent replay attacks

Signature Generation Process

name.com generates signatures using the following process:
  1. Convert payload to object and sort keys alphabetically
  2. JSON encode the sorted payload
  3. Combine the exact full webhook subscription URL and JSON payload with a pipe delimiter (<full_webhook_url>|<sorted_json_payload>)
  4. Compute HMAC using the specified algorithm, combined data, and your API token (earliest if multiple exist)
  5. Convert binary signature to hexadecimal and prefix with algorithm name
  6. Generate Unix timestamp and unique nonce (UUID)
  7. Combine signature, timestamp, and nonce as comma-separated values

Accounts with multiple API tokens

  • Webhook HMAC is computed with your account’s earliest API v4 token.
  • If the account has only one token, that token is the signing key.

URL Canonicalization Requirement

When verifying X-NAMECOM-SIGNATURE, construct the HMAC input using the exact full webhook subscription URL (including scheme, host, and path; include query string if present), not a path-only value. Canonical input format: <full_webhook_url>|<sorted_json_payload>.

Verification Examples

PHP

Python

Go

JavaScript (Node.js)

Java

Ruby

Important Notes

  1. Key Sorting: The payload keys must be sorted alphabetically before JSON encoding to ensure consistent signature generation.
  2. JSON Encoding: Use consistent JSON encoding settings across all implementations to match name.com’s signature generation.
  3. URL Inclusion: Use the exact full webhook subscription URL in the signature calculation (<full_webhook_url>|<sorted_json_payload>), not a path-only value.
  4. Timing-Safe Comparison: Always use timing-safe comparison functions to prevent timing attacks when comparing signatures.
  5. Timestamp Validation: The timestamp validation prevents replay attacks by rejecting signatures older than the specified time window (default 5 minutes).
  6. Nonce Usage: While the nonce is included in the header for uniqueness, it’s not used in signature verification but helps with request tracking and debugging.
  7. Error Handling: Implement proper error handling for invalid header formats, timestamp validation failures, and unsupported algorithms.
  8. Character Encoding: Ensure consistent UTF-8 encoding across all implementations.
  9. Algorithm Support: The examples support dynamic algorithm detection from the signature header, allowing for future algorithm changes.
  10. Security: The combination of HMAC signature (including full URL), timestamp validation, and nonce provides strong protection against replay attacks and cross-endpoint attacks while ensuring request authenticity.
  11. Testing: Test with the same payload, API token, and webhook URL to ensure all implementations produce identical results.