ExpressConsent

Go live

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 two 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.

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

  • 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 sdk.expressconsent.com. If you set the nonce, crossorigin, or referrerpolicy attributes on the script tag, they are copied onto the bundle the loader injects.
  • async or defer is still on the script tag. Without one of them, a failed request for the modern bundle is never retried against the compatible one.
  • 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.

Next

TroubleshootingSymptoms you can see, the cause behind each one, and the change that fixes it.SDK errorsEvery error the capture call can throw, what causes it, and whether retrying helps.