Go live

Required release gate

Before release, make a capture with devMode: true and inspect the finished visual record in the dashboard. Test the smallest and largest supported viewports, every supported browser family, and form states such as validation errors or expanded disclosures. The complete disclosure, entered values, consent state, and pressed submit control must all be visible.

Remove Dev Mode before real traffic

After the rendered evidence passes, remove devMode: true from captureCDR() and make one final production capture. Dev Mode CDRs are free test artifacts: they cannot be collected or transferred through the API and do not provide production download access.

Test with Dev Mode covers the complete verification workflow.

Failing safely

If you receive a cdrId, the record is durably stored. That is the guarantee the call makes.

Everything else is a transient real-world failure: such as a consumer on a bad connection. For those, decide three things up front. First, how you log the error codes the SDK returns, so failures are something you can see. Second, whether you want to reattempt the capture; the SDK already retries transient failures before it throws. Third, the longest a person should wait on your submit button. The call settles within 130 seconds by default; set timeoutMs for a shorter limit. See captureCDR().

Never block a submission because evidence capture failed

Every call to captureCDR() belongs inside try/catch, and the catch should log and continue.

Log error.code, and error.details.backendCode when it is present. If you would rather not wrap every call site, every SDK error is also dispatched on window as an expressconsent:error event. See SDK errors.

Production configuration

devMode is absent. Do not ship devMode: true; an explicit false is unnecessary.
inlineAssets is off. It exists for local development, where our renderer cannot reach localhost asset URLs. Left on in production it multiplies payload size and starts failing captures with PAYLOAD_TOO_LARGE.
Your Content Security Policy allows both of our hosts. script-src needs sdk.expressconsent.com; the script is a single file and loads nothing else, so a nonce on the script tag is all it needs. connect-src needs sdk.expressconsent.com and expressconsent-prod-sdk.web.app: the SDK sends evidence to the second host when the first cannot take it, so blocking it removes the backup. If you load the script with the backup-URL snippet from window.ExpressConsent, add expressconsent-prod-sdk.web.app to script-src too.
async or defer is still on the script tag. The script is not needed until a form is submitted, so it should not block your page from rendering.
The script is in the same document as every form it captures. A form injected through an iframe needs the script inside that iframe.

What you are storing

custom holds what you will search by. The phone number, the email, your own lead identifier. When a complaint arrives naming a phone number eighteen months from now, this is how you find the record that answers it.
custom is validated by you, not by us. The limits are applied when the record is processed, so an oversized object returns a cdrId for a record that never appears. Check the limits on captureCDR().
Password, payment, and identifier fields carry a redaction attribute. Every field on a captured page is stored unless you tag it. See redact sensitive fields.

If you hand evidence to buyers

Decide where the share URL comes from. Use autoShare on the capture when you want the share URL to travel with the lead, which is the typical case. Use the share endpoint from your server when you need to generate one later.
Decide who pays. Auto-collect is on by default for organizations with billing set up, which makes you the payer for records captured on your own sites. Turn it off if your buyers should be the payers. See access and collection.