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 (secret, 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

MD5 presets

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

Values only

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

  • md5(v1|v2|v3|secret)

Key value pairs

You build key=value pairs, join them, then add 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 secret is appended after data
  • Prefix means 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 shared 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 · B · SHA-256/512

Signs the raw body.

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

HMAC · TS+B · 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 – Secret, Timestamp.
  • Typical output placement – X-Timestamp: <ts> 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 – Secret.
  • Typical output placement – X-Signature: <base64(signatureBytes)>

Digest · B (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 · Signed Headers (bytes) · HMAC-SHA256/512

Signs a canonical string built from selected headers.

  • Input used for signing – Canonical string bytes built from the Signed Headers list in the given order.
  • Algorithm – HMAC SHA-256/512.
  • Requires – Secret, Signed Headers list.
  • Typical output placement – Signature: <base64(signatureBytes)> or Authorization: Signature <…>

HSIG + Digest (Base64) · SH (bytes) · HMAC-SHA256/512

Computes Digest from body and signs a canonical string that can include that Digest.

  • Input used for signing – Canonical string bytes built from the Signed Headers list, with Digest header value available as an input.
  • Algorithm – Digest uses SHA-256/512 then Base64, signature uses HMAC SHA-256/512.
  • Requires – Secret, Signed Headers list, Body (if Digest is included).
  • Typical output placement – Digest: <…> plus Signature: <base64(signatureBytes)> or Authorization: Signature <…>

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 – 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 · B · SHA-256
  • HMAC · B · SHA-512
  • HMAC · TS+B · SHA-256
  • HMAC · TS+B · SHA-512
  • HMAC · Params A→Z · SHA-256
  • HMAC · Params A→Z · SHA-512
  • Digest · B (Base64) · SHA-256
  • Digest · B (Base64) · SHA-512
  • HSIG · Signed Headers (bytes) · HMAC-SHA256
  • HSIG · Signed Headers (bytes) · HMAC-SHA512
  • HSIG + Digest (Base64) · SH (bytes) · HMAC-SHA256
  • HSIG + Digest (Base64) · SH (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.

Insights that
helps you grow

  • Release notes 2025/12/19
    We added country-based categorization. You can now categorize offers, integrations, and other items by a specific country, or keep them global across all markets. We also…
  • Release notes 2025/12/17
    More flexible lead rejection: based on validation rules, filters, or pingtree sales results, by source (iframe, API) or by partner (include / exclude). It is now possible to…
  • Case study: How Lender Orka Ventures Scaled Affiliate Operations
    Orka Ventures, an online lending group that wanted to scale fast across countries and onboard affiliates quickly. Their custom affiliate API and tracking layer soon…