We have introduced a new verification content type for stops that enables client-side verification workflows, such as verifying a recipient’s date of birth or entering a PIN code.

The verification value is provided as an argon2id hash. The backend only validates that the value is a structurally valid argon2id hash — it never sees the plaintext. The driver app collects input from the recipient and verifies it locally against the hash.

Important: While hashing obscures the plain text, it does not keep the value secret. Values with small problem spaces — such as birth dates (~37,000 possible values in the last 100 years) or short numeric PIN codes — can still be brute-forced. Argon2id makes this computationally harder, but these values should not be considered secret.

The choice of argon2id parameters is up to the requestor. The RFC 9106 “first recommended” configuration is a good starting point.

When using the date value type, the date must be formatted as YYYY-MM-DD (ISO 8601 calendar date) before hashing with argon2id.

This new content type can be used when creating or updating stops:

Data retention: Once a booking or tour is operationally completed (reaches done, paid, or cancelled state), all verification content values are automatically anonymized. The value field is replaced with a random argon2id hash. The content item itself is preserved as a record that verification was requested.

Instruction templates with variables

Stop instructions provide a convenient way to add common tasks at stops without having to provide the full custom content schema payload. You can see available instruction templates via the dedicated endpoint:

Two new instruction templates are now available that use verification content with dynamic variables:

• birthday_verification — requires a birthdate_argon2id variable (the recipient’s date of birth, hashed with argon2id)
• pin_code_verification — requires a code_argon2id variable (a delivery PIN code, hashed with argon2id)

Instructions can now be passed as objects with a key and variables field, in addition to the existing plain string format. Existing plain-string instructions continue to work unchanged.

{
  "instructions": [
    { "key": "birthday_verification", "variables": { "birthdate_argon2id": "$argon2id$..." } }
  ]
}

Each template’s required variables and their schemas can be introspected via the variables_schema field on the list available instructions endpoint shown above.