Signature

The Signature card lets you sign an outgoing HTTP request using a predefined preset. Each preset describes exactly how the signature is computed, which parts of the request are used as input, and how the result should be produced.

Important: presets are not customizable. If you need a different signing rule, we add a new preset based on your requirements.

How it works

1. Build your HTTP request as usual (URL, method, headers, query parameters, body).
2. In the Signature card you select a preset.
3. You fill required inputs for that preset (delimiter, etc.).
4. PalDock calculates the signature using the selected preset rules.

How to choose a preset

Pick the preset based on what the partner documentation says you must send.

• If the partner says “send X-Signature computed from the request body” → HMAC · B
• If the partner says “signature = HMAC(timestamp + body)” or mentions replay protection with a timestamp → HMAC · TS+B
• If the partner says “sign parameters sorted alphabetically” or shows examples where keys are sorted → HMAC · Params A→Z
• If the partner says “send a Digest header” or shows Digest: SHA-256=… → Digest · B (Base64)
• If the partner says “HTTP Signatures”, “Signature header”, “Authorization: Signature”, “signed headers”, or “(request-target)” → HSIG · Signed Headers
• If the partner says “HTTP Signatures” and also requires a Digest header included in the signature → HSIG + Digest
• If the partner explicitly requires the fixed list timestamp, host, request-target, digest with lowercase names and newline separated canonical string → HSIG + Digest … (TS,H,RT,DIG) NL LC

What to search for in partner documentation

Search for these keywords, they usually reveal the required preset.

• HMAC
• X-Signature
• Digest
• Signature header
• Authorization: Signature
• signed headers
• (request-target)
• canonical string
• Base64
• SHA-256 or SHA-512
• timestamp, date header, replay protection

Secrets

Create the required signing values as local parameters in each integration. Use sign_secret as the shared secret key for all MD5 and HMAC presets. Set sign_keyid only for presets that include a key identifier, for example the HMAC KeyId variants.

MD5 presets

MD5 presets compute an MD5 hash from request parameters and a sign_secret. There are two main shapes:

Values only

You take only parameter values (not keys), join them, then add sign_secret, then hash. Example pattern:

• md5(v1|v2|v3|secret)

Key value pairs

You build key=value pairs, join them, then add sign_secret, then hash. Example pattern:

• md5(k1=v1&k2=v2&secret=XYZ)

Ordering rules

• As sent means the order is the same as the parameter order in the request editor
• A to Z means parameters are sorted alphabetically by key name before building the input string

Secret position

• Suffix means sign_secret is appended after data
• Prefix means sign_secret is placed before data

Available MD5 presets

These presets are combinations of:

• input format: Values vs Key value
• ordering: As sent vs A to Z
• secret position: Prefix vs Suffix
• delimiter: provided as an input when needed

Available MD5 presets:

• MD5 · Values · As sent · Suffix
• MD5 · Values · As sent · Prefix
• MD5 · Values · A to Z · Suffix
• MD5 · Values · A to Z · Prefix
• MD5 · Key=Value · As sent · Suffix
• MD5 · Key=Value · As sent · Prefix
• MD5 · Key=Value · A to Z · Suffix
• MD5 · Key=Value · A to Z · Prefix

Advanced presets

Advanced presets cover the most common modern partner requirements, such as signing the raw body with HMAC, generating a Digest header from the body, or using HTTP Signatures where the signature is computed from a canonical string built from selected headers. These presets typically produce signature bytes that you then Base64 encode when sending them.

Legend

• HMAC – Hash based Message Authentication Code. Output is signature bytes computed from input data and a sign_secret.
• Digest – A hash of the request body. Often required as a header and often used as an input to HTTP Signatures.
• HSIG – HTTP Signatures style signing. Builds a canonical string from selected headers and pseudo headers and then signs it with HMAC.
• B – Body. Specifically the raw request body bytes exactly as sent.
• TS – Timestamp header value that is included in the signed input.
• Params A→Z – All request parameters are normalized and sorted by parameter name A to Z before signing.
• SH – Signed Headers list. The ordered list of headers and pseudo headers used to build the canonical string.
• RT – Request Target pseudo header. Usually method plus path, like:
  (request-target): post /api/v1/leads
• DIG – Digest header included in the signed headers list.
• NL – Newline separator \n between canonical string lines.
• LC – Lowercase header names in the canonical string.
• bytes – The preset outputs raw signature bytes. You typically Base64 encode these bytes when you place them into a header or field.

HMAC · Body · SHA-256/512

Signs the raw body.

• Input used for signing – Raw body bytes.
• Algorithm – HMAC SHA-256/512.
• Requires – sign_secret.
• Typical output placement – X-Signature: <base64(signatureBytes)>

HMAC · Timestamp + Body · SHA-256/512

Signs timestamp plus raw body.

• Input used for signing – Timestamp value concatenated with raw body bytes.
• Algorithm – HMAC SHA-256/512.
• Requires – sign_secret, Timestamp.
• Typical output placement – X-Timestamp: <ts> and X-Signature: <base64(signatureBytes)>

HMAC · TS,NONCE,M,PATH,Q,BH · SHA-256/512

Signs timestamp, nonce, HTTP method, request path, canonical query string, and body hash.

• Input used for signing – Canonical string built from Timestamp, Nonce, HTTP method, request path, canonical query string, and SHA-256 hash of raw body bytes, joined in that exact order with newline separators.
• Algorithm – HMAC SHA-256.
• Requires – sign_secret, Timestamp, Nonce, Method, Path, Query parameters, Body.
• Typical output placement – X-Timestamp: <ts>, X-Nonce: <nonce>, and X-Signature: <base64(signatureBytes)>

HMAC · Params A→Z · SHA-256/512

Signs request parameters sorted by name.

• Input used for signing – Normalized parameters (query and body fields) sorted A to Z and serialized into one byte sequence.
• Algorithm – HMAC SHA-256/512.
• Requires – sign_secret.
• Typical output placement – X-Signature: <base64(signatureBytes)>

Digest · Body (Base64) · SHA-256/512

Computes a Digest from the raw body and Base64 encodes it.

• Input used for signing – Raw body bytes.
• Algorithm – SHA-256/512 then Base64.
• Requires – None.
• Typical output placement – Digest: SHA-256=<base64(sha256(body))> or Digest: SHA-512=<base64(sha512(body))>

HSIG + Digest (Base64) · SH (TS,H,RT,DIG) NL LC · HMAC-SHA256/512 (bytes)

HTTP Signatures preset with fixed signed items and formatting rules.

• Input used for signing – Canonical string bytes composed of timestamp, host, request-target, and digest in that exact order, separated by newline, with lowercase item names.
• Algorithm – Digest uses SHA-256/512 then Base64, signature uses HMAC SHA-256/512.
• Requires – sign_secret, Timestamp, Host, Method and path for request-target, Body.
• Typical output placement – Digest: <…> plus Signature: <base64(signatureBytes)> or Authorization: Signature <…>

Available advanced presets

• HMAC · Body · SHA-256
• HMAC · Body · SHA-512
• HMAC · Timestamp + Body · SHA-256
• HMAC · Timestamp + Body · SHA-512
• HMAC · Params A→Z · SHA-256
• HMAC · Params A→Z · SHA-512
• Digest · Body (Base64) · SHA-256
• Digest · Body (Base64) · SHA-512
• HSIG · Signed Headers (bytes) · HMAC-SHA256
• HSIG · Signed Headers (bytes) · HMAC-SHA512
• HSIG + Digest (Base64) · SH (TS,H,RT,DIG) NL LC · HMAC-SHA256 (bytes)
• HSIG + Digest (Base64) · SH(TS,H,RT,DIG) NL LC · HMAC-SHA512 (bytes)

If you need a signature preset we do not support yet, let us know and we will add it.

Common pitfalls

• Body based signing is byte sensitive. Whitespace, JSON formatting, and field order can change the signature if the partner recomputes it differently.
• Parameter signing depends on scope. Confirm whether the partner expects query parameters only or query plus body fields.