Getting started

From zero to a running synthetic-disputes sandbox in five minutes.

Sign up. Use any email address you control — the portal sends a six-digit verification code via Envoi, and every route stays locked behind a /verify-email gate until you enter it. Optional company name is captured on the form and surfaces in the sidebar / top bar.
Generate a starter dataset. Open the Dev panel from the sidebar and run Generate. Pick a transaction count (up to 5,000), dispute rate (0–1), currency, and a time range in days. The generator emits transactions, disputes, evidence-required records, and the matching payment-event timeline in one batch.
Walk a dispute end-to-end. Open the Disputes list and pick a row with status evidence_required. You have three options:
- Challenge. Add evidence (upload a file, then finalise the record with a kind: receipt, shipping proof, communication, refund policy, service documentation, or other), then submit. Status moves to under_review.
- Accept. Mark liability and move on. Status moves to accepted; the disputed amount is debited.
- Ignore. Let the response window expire. The hourly background job flips the status to expiredonce respond_by is past.
Advance the lifecycle.Don't want to wait for the hourly cron? The Dev panel's Advance lifecyclebutton runs the same job on demand, expiring overdue RFIs and evidence-required disputes and ruling on under_review disputes whose 55-day issuer window has elapsed (~60% won / ~40% lost).
Export a report. The Reports page lets you queue a transactions or disputes CSV report. The portal downloads the file through a short-lived presigned URL.

What you should know upfront

Everything is synthetic.No real card networks, no real money movement. Reset state from the Dev panel any time — it wipes your tenant's synthetic data and leaves the account itself untouched.
Two surfaces, one product. The portal and the API (/v1/*) hit the same models. Your agents can click through the UI like a human or call the API directly — same data, same events, same audit trail.
RBAC included. Owner accounts have full access. Create synthetic accounts from the Team page with one of: full access, disputes-only, reports-only, or view-only.

How a synthetic account gets its password

When you create a synthetic account on the Team page, the Password choice decides who ever holds its password. You can switch an existing account either way from its Edit dialog.

	Generate it now	Email a setup link
Who sees the password	You, once, right after you create the account.	Only whoever opens the link and types it. You never see it.
Sign-in address	Optional: a plus-address of one of your verified emails, or a bot address on `agents.dispute.markets`.	Required: a plus-address of one of your verified emails (see below).
Can sign in	Straight away.	Once someone has used the link.
Two-factor	The authenticator secret or recovery codes are shown to you with the password.	Set up on the link’s page and shown only there. Authenticator app, or email codes sent to the sign-in address.
Changing the password later	Rotate password, from the account’s ⋯ menu.	The inbox holder uses Forgot password, or you send a new setup link.

Pick Generate when you configure the agent yourself: you paste the password (and TOTP secret) into your CI secret store and nobody else needs it.
Pick Email a setup link when someone else operates the agent, or when you should not hold its credentials: the person or agent reading that inbox sets them, and you only see whether the account is set up.
In email mode Rotate MFA and Rotate all are not offered, because they would show you a new authenticator secret. Disabling two-factor and archiving still work.

Plus addresses

Every synthetic account needs its own sign-in address, so we derive one from an email you already own by adding a tag after a +. Mail to it lands in the original inbox:

ops@acme.com becomes ops+agent-7k2m9qx4bd@acme.com.
An address that already has a tag keeps it, folded into one: ops+qa@acme.com becomes ops+qa-agent-7k2m9qx4bd@acme.com, so a filter on +qa still matches.
The base must be one of your verified emails (the Team dialog lets you add and verify one with a 6-digit code). Addresses on dispute.markets domains cannot be used.
The part before the @ may be at most 47 characters (including any tag of yours), so the 17-character +agent-… tag still fits the 64-character limit.
Your mail provider must deliver + addresses. Gmail, Google Workspace, Outlook.com and Microsoft 365 do; some corporate mail gateways do not.

Delivery failed on an account means the setup email bounced (or the address was reported as spam). That address is then blocked for setup emails and the link stops working. Open Change email… and pick a different verified email, for example one at a provider that accepts + addresses.

The setup link

It comes from notifications@dispute.markets, names the account, its sign-in address and your workspace, and opens the portal's setup page.
It works once and expires after 72 hours. An expired link is never resent automatically; send a new one from the account's ⋯ menu.
Sending a new link (Resend, or a changed email) makes the older one stop working. Only the most recent email counts.
Opening the page uses nothing; only pressing Set password does. Mail scanners that open links in advance cannot burn it.
Switching an account from a generated password to email signs it out at once: its password is replaced, every session ends and its two-factor is turned off. It cannot sign in until the link is used. Sending a new link to an account whose link was already used does the same. Switching back to a generated password shows you a new one once, and any unused link stops working.
Changing the emailchanges the account's sign-in address and sends the link there; the old address stops working for sign-in. An account whose link was already used is signed out first, as above.
Only the workspace owner can send setup links. No API key can, and sending is rate-limited (see the API reference).