Journey templates

A journey template is guidance for one common moment of your product: when your backend calls POST /v1/assessments, which pseudonymous references to send and what to look at on the console afterwards. Templates exist only in this documentation and in the console’s integration guide. Nothing of them is stored, and they have no effect on the assessment: every v1.1 request runs the same internal behaviour, so the same evidence gives the same score under any tag (journeys and tags).

The suggested tag is only a suggestion. You may send any valid tag instead, for example saque instead of withdrawal; the console shows the tag you send.

The v1.1 request

Templates describe the v1.1 request, which production accepts. An integration that stays on v1 keeps its three fixed journeys, unchanged.

The ten templates

Template	Suggested tag	When your backend calls	subject_ref	account_ref
Account creation	signup	After your backend validates the form, before it activates the account	Recommended (a new pseudonym)	Recommended (a new pseudonym)
Login	login	After your backend checks the credential, before it issues the session	Recommended when the user is identified	Recommended with subject_ref
Password recovery	password_recovery	When the password is actually changed, not when the reset link is requested	Recommended only if your backend already resolved the user; never the email	null
Two-step verification	mfa_challenge	When your backend validates the code	Recommended	Recommended
Profile change	profile_change	When your backend saves a new email, phone number or address	Recommended	Recommended
Deposit	deposit	When your backend issues the charge (QR code, boleto)	Required	Required
Withdrawal	withdrawal	When the user confirms, before your backend settles	Required	Required
Transfer or Pix	pix_transfer	When the user confirms, before your backend settles	Required	Required
Order	trade	When your backend accepts the order, before it routes it	Required	Required
Checkout	checkout	When the user confirms the payment, before your backend captures it	Recommended	Optional

account_ref requires subject_ref: when a template marks the account reference as required, the subject reference is required too, and a template that recommends account_ref recommends it together with subject_ref. Both are pseudonyms your backend creates; never send an email, tax ID, phone number, name or account number. Send the same account_ref with the same subject_ref on every call: an account stays bound to the person it was first sent with, and another subject_ref returns 409 binding-conflict (person and account references).

The console items about an account (a new device for the account, other accounts on the same devices, events with the same tag on the same account) need account_ref: without it they show Conta não informada pelo sistema da empresa. The account’s history starts at its first access: with a completed browser collection, that access shows Primeira vez: ainda sem histórico (first time: no history yet), and without one Sem coleta concluída do navegador (no completed browser collection). A later access evaluates Dispositivo novo para esta conta only when an earlier access of the same account in the last 90 days also had a browser collection whose browser installation was linked; after more than 90 days without one, it shows Primeira vez again (person and account references).

Rules every template repeats

• The tag carries no personal data: no email, tax ID, name, user ID or Pix key. It has at most ten digits in total.
• recommended_action is advice, not an action taken: your system decides and acts.
• The same evidence gives the same score under every template and every tag.
• A retry repeats the whole body, tag included. Changing any field except deadline_ms under the same external_event_id or idempotency_key is 409 idempotency-conflict; a retry that changes only deadline_ms is the same operation and answers 200.

A template never carries an amount, currency, order, beneficiary, deadline of its own, fallback, policy, weight, provider, signal applicability, quota, price or internal class. The v1.1 body has no field for any of them.

Template by template

Each example is a synthetic v1.1 body, formatted for reading. In the real call, send the compact JSON that JSON.stringify(object) produces, and replace the token with the one the Web SDK returned for that action, or null when there is none.

Account creation

• Suggested tag: signup
• Call: after your backend validates the form, before it activates the account.
• References: subject_ref recommended (a new pseudonym); account_ref recommended (a new pseudonym).
• Look at on the console: DEVICE_MULTI_USER, BOT_AUTOMATION and EMULATED_ENVIRONMENT; other accounts seen on the same device (needs account_ref); events with the same tag on the same device (many sign-ups from one device).

{
  "schema_version": "event-assessment-request.v1.1",
  "external_event_id": "evt_signup_0001",
  "idempotency_key": "idem_evt_signup_0001",
  "occurred_at": "2026-11-03T14:05:22.481Z",
  "subject_ref": "usr_5c0e",
  "account_ref": "acc_77d2",
  "event_context_token": "ect_signup_0001",
  "tag": "signup",
  "deadline_ms": null
}

Login

• Suggested tag: login
• Call: after your backend checks the credential, before it issues the session.
• References: subject_ref recommended when the user is identified; account_ref recommended, always together with subject_ref.
• Look at on the console: BOT_AUTOMATION and BROWSER_SPOOFING; NETWORK_TOR, NETWORK_VPN and NETWORK_HOSTING; a new device for the account (needs account_ref).

{
  "schema_version": "event-assessment-request.v1.1",
  "external_event_id": "evt_login_0001",
  "idempotency_key": "idem_evt_login_0001",
  "occurred_at": "2026-11-03T14:05:22.481Z",
  "subject_ref": "usr_5c0e",
  "account_ref": "acc_77d2",
  "event_context_token": "ect_login_0001",
  "tag": "login",
  "deadline_ms": null
}

Password recovery

• Suggested tag: password_recovery
• Call: when the password is actually changed, not when the reset link is requested.
• References: subject_ref recommended only if your backend already resolved the user; never the email; account_ref null.
• Look at on the console: NETWORK_TOR, NETWORK_VPN and NETWORK_HOSTING; PRIVATE_BROWSING; devices seen for the person.

{
  "schema_version": "event-assessment-request.v1.1",
  "external_event_id": "evt_password_recovery_0001",
  "idempotency_key": "idem_evt_password_recovery_0001",
  "occurred_at": "2026-11-03T14:05:22.481Z",
  "subject_ref": "usr_5c0e",
  "account_ref": null,
  "event_context_token": "ect_password_recovery_0001",
  "tag": "password_recovery",
  "deadline_ms": null
}

Two-step verification

• Suggested tag: mfa_challenge
• Call: when your backend validates the code.
• References: subject_ref recommended; account_ref recommended.
• Look at on the console: continuity with the login device: a new device for the account (needs account_ref), or a lost device cookie.

{
  "schema_version": "event-assessment-request.v1.1",
  "external_event_id": "evt_mfa_challenge_0001",
  "idempotency_key": "idem_evt_mfa_challenge_0001",
  "occurred_at": "2026-11-03T14:05:22.481Z",
  "subject_ref": "usr_5c0e",
  "account_ref": "acc_77d2",
  "event_context_token": "ect_mfa_challenge_0001",
  "tag": "mfa_challenge",
  "deadline_ms": null
}

Profile change

• Suggested tag: profile_change
• Call: when your backend saves a new email, phone number or address.
• References: subject_ref recommended; account_ref recommended.
• Look at on the console: a new device for the account (needs account_ref); NETWORK_TOR, NETWORK_VPN and NETWORK_HOSTING.

{
  "schema_version": "event-assessment-request.v1.1",
  "external_event_id": "evt_profile_change_0001",
  "idempotency_key": "idem_evt_profile_change_0001",
  "occurred_at": "2026-11-03T14:05:22.481Z",
  "subject_ref": "usr_5c0e",
  "account_ref": "acc_77d2",
  "event_context_token": "ect_profile_change_0001",
  "tag": "profile_change",
  "deadline_ms": null
}

Deposit

• Suggested tag: deposit
• Call: when your backend issues the charge (QR code, boleto).
• References: subject_ref required; account_ref required.
• Look at on the console: a new device for the account; NETWORK_TOR, NETWORK_VPN and NETWORK_HOSTING; events with the same tag on the same account. The account items need account_ref, which this template requires.

{
  "schema_version": "event-assessment-request.v1.1",
  "external_event_id": "evt_deposit_0001",
  "idempotency_key": "idem_evt_deposit_0001",
  "occurred_at": "2026-11-03T14:05:22.481Z",
  "subject_ref": "usr_5c0e",
  "account_ref": "acc_77d2",
  "event_context_token": "ect_deposit_0001",
  "tag": "deposit",
  "deadline_ms": null
}

Withdrawal

• Suggested tag: withdrawal
• Call: when the user confirms, before your backend settles.
• References: subject_ref required; account_ref required.
• Look at on the console: a new device for the account; NETWORK_TOR, NETWORK_VPN and NETWORK_HOSTING; events with the same tag on the same account and on the same device.

What a v1.1 withdrawal does not show

The v1.1 request carries no amount and no beneficiary, so the context items that depend on them (shared beneficiaries, beneficiaries per device, accounts per beneficiary and the amount withdrawn in 24 hours) come back not evaluated, with a reason that says the request does not carry them. If you need them today, integrate the withdrawal with the v1 WITHDRAWAL journey, which keeps journey_context unchanged.

{
  "schema_version": "event-assessment-request.v1.1",
  "external_event_id": "evt_withdrawal_0001",
  "idempotency_key": "idem_evt_withdrawal_0001",
  "occurred_at": "2026-11-03T14:05:22.481Z",
  "subject_ref": "usr_5c0e",
  "account_ref": "acc_77d2",
  "event_context_token": "ect_withdrawal_0001",
  "tag": "withdrawal",
  "deadline_ms": null
}

Transfer or Pix

• Suggested tag: pix_transfer
• Call: when the user confirms, before your backend settles.
• References: subject_ref required; account_ref required.
• Look at on the console: the same as for a withdrawal.

What a v1.1 withdrawal does not show

The v1.1 request carries no amount and no beneficiary, so the context items that depend on them (shared beneficiaries, beneficiaries per device, accounts per beneficiary and the amount withdrawn in 24 hours) come back not evaluated, with a reason that says the request does not carry them. If you need them today, integrate the withdrawal with the v1 WITHDRAWAL journey, which keeps journey_context unchanged.

{
  "schema_version": "event-assessment-request.v1.1",
  "external_event_id": "evt_pix_transfer_0001",
  "idempotency_key": "idem_evt_pix_transfer_0001",
  "occurred_at": "2026-11-03T14:05:22.481Z",
  "subject_ref": "usr_5c0e",
  "account_ref": "acc_77d2",
  "event_context_token": "ect_pix_transfer_0001",
  "tag": "pix_transfer",
  "deadline_ms": null
}

Order

• Suggested tag: trade
• Call: when your backend accepts the order, before it routes it.
• References: subject_ref required; account_ref required.
• Look at on the console: see orders, one assessment each.

One assessment per order, with no order data. The full flow, cost and capacity notes are on orders, one assessment each.

{
  "schema_version": "event-assessment-request.v1.1",
  "external_event_id": "evt_trade_0001",
  "idempotency_key": "idem_evt_trade_0001",
  "occurred_at": "2026-11-03T14:05:22.481Z",
  "subject_ref": "usr_5c0e",
  "account_ref": "acc_77d2",
  "event_context_token": "ect_trade_0001",
  "tag": "trade",
  "deadline_ms": null
}

Checkout

• Suggested tag: checkout
• Call: when the user confirms the payment, before your backend captures it.
• References: subject_ref recommended; account_ref optional.
• Look at on the console: BOT_AUTOMATION, BROWSER_SPOOFING and EMULATED_ENVIRONMENT; events with the same tag on the same device.

{
  "schema_version": "event-assessment-request.v1.1",
  "external_event_id": "evt_checkout_0001",
  "idempotency_key": "idem_evt_checkout_0001",
  "occurred_at": "2026-11-03T14:05:22.481Z",
  "subject_ref": "usr_5c0e",
  "account_ref": null,
  "event_context_token": "ect_checkout_0001",
  "tag": "checkout",
  "deadline_ms": null
}

Choosing your own tags

• Name the moment, not the outcome: withdrawal, not withdrawal_blocked.
• Keep one tag per moment. The console never merges two tags, so saque and withdrawal are two lines in every report.
• Keep the tag stable across releases of your product: a renamed tag starts a new line on the console.