Customer identity and write confirmation

When verification is required#

Native Shopify and WooCommerce order lookups always require verified email. Built-in support and return requests also require it. For custom HTTP, the Verify customer email before execution setting defaults to on. Keep it enabled for account data, orders and any private record.

When the assistant has collected the operation’s required inputs, the widget presents a dedicated verification form. The customer enters the email used for their order or account, requests a code and enters that code in the widget. Do not ask them to paste the code into ordinary chat or to send it to staff.

The ordinary website login and the Action verification form are separate. Do not assume that a signed-in storefront visitor already has a verified Action identity simply because an account name is visible on the page.

Code and identity lifetime#

The emailed code has six digits and expires after 10 minutes. There are at most five verification attempts for an issued code. A resend has a 60-second cooldown, with additional request rate limits. After a successful check, the identity remains verified for 30 minutes in that conversation; it is not a permanent website login.

An expired or invalid code requires a new verification attempt through the form. An expired verified identity requires verification again for a private operation. Receiving a code does not extend a pending proposal indefinitely: proposals expire after 10 minutes. If the proposal has expired, ask for the operation again and review its new details.

Requesting verification for a different address replaces the conversation's current verification attempt and clears its previous verified state. Use the address relevant to the record rather than changing addresses repeatedly within the same task.

What verification does and does not authorize#

Verification shows that this visitor controls the supplied mailbox. Native order adapters compare that email with the order’s email before returning any result. A mismatch produces a not-found result rather than another customer’s details.

Custom endpoints must do the same ownership check themselves, using the dedicated verified identity supplied by Reesponder. A visitor-provided name, account ID, order reference or email inside an input field is not verified identity. Business policies may require additional checks before a write, even when the email matches.

Email comparison is not a general account recovery process. If the customer no longer controls the recorded mailbox or the order belongs to an organization with different access rules, direct them to your established support process instead of weakening the lookup.

Customer controls for reads and writes#

A read can run immediately if identity is unnecessary or already verified. When verification was needed for a pending lookup, the widget shows Continue after verification. A write requires Confirm & submit after showing the exact collected inputs. The customer can select Cancel instead.

Reesponder does not treat “yes” somewhere in a previous conversation as approval for an arbitrary write. The operation is tied to its saved Action revision and fixed input details. Saving changes or pausing the Action cancels pending proposals, preventing an old confirmation from using newly edited configuration.

A completed verification can be reused within its bounded conversation window, but each write still needs its own exact proposal. Identity and approval answer different questions: who is present, and which operation they are authorizing.

When the customer cannot continue#

If no email arrives, check the address and spam folder, then wait for the resend cooldown. A temporary verification-unavailable response may mean the delivery service is unavailable. Do not bypass verification for private data while troubleshooting.

If the code succeeds but the order remains not found, confirm the exact order reference and the address recorded on the order. Do not repeatedly try other customers’ emails. If the Action reports cancelled, confirm whether its proposal expired or your team edited or paused the definition. Request a fresh proposal and review it before confirming.

If the conversation has expired or is unavailable, the old form cannot authorize a new operation. Start through the supported widget conversation and request a fresh task. Do not transplant a code or proposal from another browser session.

Worked example: verify first, then confirm the request#

A visitor asks to change the delivery date of ORDER-1042. The Action collects the reference and requested date. The visitor uses the dedicated form to verify the email recorded on that order, entering the six-digit code only in the widget control. The private endpoint must then compare that verified address with the order owner.

Mailbox verification does not execute the change. The widget displays the prepared fields and offers Confirm & submit. The visitor can cancel if the date or reference is wrong. Do not treat a message saying “yes, please” earlier in chat as approval for details that were subsequently collected or changed.

Your endpoint rechecks whether the order is still eligible for a delivery change when it receives the confirmed request. If dispatch has already started, return a factual result such as “Change unavailable after dispatch” according to your contract. Confirmation cannot force your business system to accept an ineligible mutation.

If the proposal expires while the visitor retrieves the email, request a fresh proposal and review its details again. If the endpoint's outcome becomes unknown, investigate the run reference before creating a second confirmed write. A new verified identity does not settle an uncertain previous operation.

Test identity and approval as separate controls#

Use your own addresses and fixtures to test a valid code, an invalid code, an expired attempt and a resend during cooldown. Then verify the correct mailbox against an order owned by another address; the provider should still withhold the record. This establishes that mailbox control and record ownership are both being checked.

For writes, cancel a correctly prepared proposal and verify no destination mutation. Test a fresh proposal after editing or pausing the Action. Record safe statuses and references, keeping codes, tokens and private order details out of shared screenshots.

Understand the two clocks in the customer flow#

Email verification and the Action proposal have independent lifetimes. A code can be entered only within its ten-minute code window and allowed attempt count. A successfully verified identity lasts thirty minutes in that conversation. The proposal itself lasts ten minutes, so a still-verified person can nevertheless be looking at an expired operation.

For example, a customer verifies immediately but leaves the proposal open for fifteen minutes. They must request a new proposal. They may still have a valid identity in that conversation, but they must review and confirm the newly prepared write. The old proposal is not extended simply because verification succeeded.

Conversely, a customer who returns much later may need both a fresh proposal and a new email verification. A remembered conversation identifier in the browser is not proof that the identity grant remains current. The server checks the live conversation and verification state before execution.

This distinction is useful for support. First determine whether the code attempt, identity grant or proposal expired. Ask the customer to continue through the relevant widget control instead of telling them to reuse a code, refresh until something runs or send verification codes to staff.

Give customers a clear recovery path#

When an email is delayed, explain which address they entered and ask them to check spam or filtering. Wait for the resend cooldown before requesting another code. A resend creates a new attempt; the customer should use the current code in the same widget form. If delivery is unavailable, keep the private operation unavailable and provide your normal support contact.

When verification succeeds but the order is not found, check the exact reference and the order's recorded email using authorized staff tools. Do not confirm whether unrelated private orders exist. A customer using a forwarding address or a different checkout address may need the established support process to resolve the discrepancy.

When a write proposal is cancelled or expired, explain that no pending confirmation remains. Ask for a fresh task, then let the visitor review its current details. Do not attempt to revive a proposal after your team has edited or paused the Action.

For sensitive changes, your destination can require additional checks beyond mailbox ownership. Set those rules in the business system and explain the supported outcome. The verification form is a specific identity signal within the conversation, not universal permission to manage the customer's account.