Test mode

Test mode lets you build and demo an integration on the hosted platform, under your own account, without cost and without legal effect. Nothing in test mode is billed, no document has legal value, and nothing you do there can touch your production data.

How it works: the test twin

Each root organization can enable its test twin: a second organization, linked to the first and flagged environment: "test", that you shape freely, like a sandbox. It starts empty (one default entity, Entité de test): create the entities, groups and roles you need to test, nothing goes back to production. It is the same idea as the test mode of a payment platform: two separate worlds under one account, and the account menu to move between them.

An owner of the organization enables it, in the app: Administer <Organization> → Test mode → Enable test mode. Only owners can enable, reset or disable it.
Members whose role includes the Access test mode permission (test_mode.access) then find the test organization in the entity selector (top left of the app), marked with an orange Test badge; Back to production in the same menu returns to production. While no test organization exists, owners find Create a test environment there. Owners and administrators have it by default; you can add it to a custom role, for example a “Developer” role for the person building the integration.
Access follows production: people holding the permission get into the test organization (at the organization level and as administrator of the default entity if that is where they hold it, otherwise on the default entity, with the same role), and lose it when the permission is withdrawn in production. Inside the test organization they can be moved and their role changed; nobody can be invited there directly. A permanent orange band reminds you that you are in test mode, with a button to go back to production.
Test data and production data never mix: every object lives in exactly one of the two organizations.

Test API keys

API keys are created in the test organization: open the test organization from the entity selector, then Administer → Integrations → API keys. A test key is marked with a Test badge, works exactly like a production key (same authentication, same endpoints, same scopes) and can only see the data of the test organization. A production key never reads test data, and a test key never reads production data.

Webhook subscriptions follow the same rule: create them in the test organization to receive the events of your test data on your test endpoint.

# Same API, same base URL: only the key (and so the organization) changes.
export MLT_API_URL=https://api.example.com
export MLT_CLIENT_ID=<client id of the TEST key>
export MLT_CLIENT_SECRET=<its secret>

`livemode` in webhooks

Every webhook event says which world it comes from, in the payload and in a header:

Where	Test event	Production event
Payload field `livemode`	`false`	`true`
Header `X-MLT-Livemode`	`false`	`true`

{
  "id": "0192f3b0-12c4-7e8a-b3d1-5f6a7b8c9d0e",
  "type": "signature.completed",
  "apiVersion": "1",
  "createdAt": "2026-10-01T10:12:45.000Z",
  "providerId": "0192f3a1-7c2e-7b4d-9a61-100000000001",
  "orgId": "0192f3a1-7c2e-7b4d-9a61-300000000001",
  "livemode": false,
  "data": { "requestId": "0192f3a1-7c2e-7b4d-9a61-400000000001", "title": "Bail - Lot 12" }
}

If you use the same endpoint for both worlds, branch on livemode so that a test event can never trigger a real action in your system. See Webhooks.

What is simulated

Test mode never uses production credentials of a vendor.

Area	In test mode
Electronic signature	Handled by the Yousign sandbox (a test account, see Testing & sandbox). Signatures have no legal value. If no test account is available for your platform, signature is unavailable in test mode.
Registered mail	The vendor sandbox (AR24 sandbox) or the registered mail simulator, whose outcome you steer with the recipient email, see Simulated registered mail vendor.
Billing	Nothing is billed, nothing is counted in your contract, and test usage is excluded from invoices and statistics.
Emails	Really sent to their recipients, with a subject prefixed `[TEST]` and a banner in the body saying the message comes from a test environment.
Documents	Every page of the documents you produce (signed PDF, proofs) carries the watermark “TEST — sans valeur légale”. They have no legal value.
Webhooks	Delivered normally, with `livemode: false`.

Test quotas

The test twin has its own, capped quotas, meant to prevent abuse and never billed:

Quota	Limit
Signature requests	50 per month
Registered mails sent	20 per month
Resource uses	100 per month
Drive storage	500 MiB (cumulative)
AI messages	100 per month
Emails	200 per day, all kinds and recipients together

Beyond a limit the API answers with the usual quota error, or test_mode_daily_email_cap for the daily email cap. These limits are independent of your production quotas.

Reset, disable and automatic purge

Reset test data deletes all the test data and starts again from the structure of the production organization.
Disable test mode deletes the test twin and everything in it. Both actions ask for the exact name of the organization (422 confirm_name_mismatch otherwise).
The twin is purged automatically after 90 days of inactivity, that is without any sign-in to the twin and without any API call on it. The owners receive a warning email 7 days before. Any activity postpones the purge.

Error codes

Code	Meaning
`test_mode_not_available`	Your provider does not offer test mode.
`test_mode_root_only`	Only a root organization can have a test twin.
`test_mode_disabled`	The test twin does not exist (not enabled, or purged).
`test_mode_daily_email_cap`	The daily email cap of the test twin is reached.
`confirm_name_mismatch`	The name typed to reset or disable does not match the organization.