Identify customers and check who belongs to your business

User identification separates proof that a person controls a phone number or email from membership in your business’s system. It is for businesses that need to check whether someone is a customer, student, employee or member. A user source checks that membership against your own system.

How it works

• Proof: does this person control this phone number or email address?
• Membership: does your business’s system have a user account for that detail?

For example, a code can prove control of an email address. It cannot prove that the address belongs to an enrolled student.

This is also different from linking customer profiles or sharing information in a customer group. Adding a source does not itself link profiles, create proof of identity, or grant access to every action.

When omotto records verification, it can check enabled sources in the background using the customer’s verified phone or email. Your connected system receives that detail for the lookup. This is separate from the manual Try it test.

You need permission to configure customer identity settings. Try it also needs permission to manage integrations. If the page or tester is missing, ask the workspace owner to check your permissions. These are business-wide source settings, not settings for an individual customer profile.

Where to find it

Customers → User identification manages user sources. For a skill’s proof requirements, open its rule in Bot → Handbook → What [assistant name] does when… → Who is this for.

Set it up

Use your Shopify store as a user source

When you connect your Shopify store, a source headed Shopify · followed by your store’s name appears switched off. You do not need to add it yourself.

1. Find the Shopify source under Who your users are.
2. Turn Enabled on to open the review.
3. Check the store and the two meanings below. The review also shows how many existing requirements name no source, when there are any.
4. Choose Turn on to enable the source, or Cancel to leave it off.

• Verified user · Shopify means qualifying verification and a current link to that store account. This can come from a verified phone or email linked to the account, or from the trusted store sign-in session described below. Verification alone, without that account link, is not enough.
• Recognized · Shopify means a match from the store’s orders, not proof that the person owns the account. Use it only if you intend to allow that weaker check.

Turning this source on also lets eligible Shopify matches satisfy Any provider requirements that name no source. It does not just affect actions where you selected Shopify explicitly.

You can change Source name or turn Enabled off. There is no response mapping, role list or Try it for Shopify. The source turns off when the store disconnects. Reconnecting the same store restores it only if the disconnect turned it off. A source you never enabled or turned off yourself stays off. Connecting a different store leaves it off until you review and enable it again.

Let store customers sign in

For website chat on your connected Shopify store, you can choose to count a signed-in store account as verified. This is separate from enabling Shopify as a user source above.

1. Under How people prove who they are, find Store account sign-in (Shopify). You need a store connection and a website line for this section to appear.
2. If permission is missing, choose Allow in Shopify and finish Shopify’s authorization and the return link to omotto. Opening the button only requests access; it does not grant it. Granting this extra permission reconnects the store. Earlier chats tied to store sign-in start fresh after that reconnect.
3. Open your published store with the standard chat installed once. Return to this page and check for Shopify permission granted and Storefront check passed with its time. A granted permission alone is not a successful check.
4. For the intended line, turn on Count signed-in store customers as verified. Read the store and line in the confirmation, then choose Turn on.
5. Leave Offer store sign-in in the chat on if you want the sign-in button offered when a customer needs verification. Turn it off to stop offering the button without turning off trust in an existing signed-in session.

After a successful sign-in, the store account stays linked to that customer’s profile, even after they sign out. Your team can still see the available store name, spending and orders. This does not join separate customer profiles. The email and phone in the store account are not treated as verified. Actions on the account, such as order access or discounts, still need a current sign-in or a qualifying verification code; membership and other action requirements still apply.

When the customer comes back to the same open page, the conversation stays on screen while the chat re-checks the sign-in in the background. New messages wait locally and are sent once the check finishes and the chat has a safe identity. If someone signs in to a different store account in that browser, a new chat starts for that account, without the previous account’s history.

The button needs customer accounts enabled in Shopify, link buttons on, line trust on, the offer on, and a current successful signed storefront check for this visitor. Unknown account settings or an unavailable check do not qualify. It is offered for a verification requirement, not every refusal. The English button is Sign in to the store; its wording follows the customer’s supported language, then the business’s default language, then English. Codes remain available.

After sign-in is confirmed, an outstanding offered action can be considered again under its normal checks. Clicking the link alone does not verify anyone or complete the action. Returning to the original page after classic Shopify sign-in is best effort and depends on the store’s theme. If needed, return to the store page with the chat yourself.

Actions check the proof that is valid now, not the sign-in status from when the bot started preparing its reply. If sign-in renews during that time and the new proof meets the action’s requirements, the customer does not need another code just because the earlier proof ended.

A connected agent can inspect this per-line setup, change the offer or turn trust off. Turning trust on requires your review in omotto; the agent’s link does not grant Shopify permission or turn trust on for you. The Coach refers you to setup rather than proposing these switches as an approval card.

Before adding a Custom API source

A Custom API source uses a read-only operation from a Custom API connection: an application programming interface that lets omotto retrieve information from your business system. The screen calls an operation a Custom API endpoint. Ask the person connecting your system to prepare it first.

The operation must:

• Be enabled, with its connection enabled too.
• Retrieve information rather than perform a real change. The Performs a real action switch must be off.
• Have exactly one identity input. Use Filled from → Value from omotto, then the verified customer phone or email. Existing Verified identity → Verified phone / Verified email rows work too. As-typed phone/email, customer names and store order numbers are not eligible lookup inputs.
• Need no required input from the conversation. Fixed inputs are allowed; optional conversation inputs are not sent during a source lookup.
• Not require a user-account match before it can run. Otherwise it would need the very answer it is meant to find.

See setting up endpoint inputs and safety for the connection workbench. A source supports a phone or an email lookup, not both at once. Prepare separate endpoints if you need both.

An endpoint already used by a source is not offered again when adding another source. Other ineligible endpoints appear disabled with an explanation.

Suggested sources

omotto looks for unused Custom API endpoints with a Verified phone or Verified email input. This is a check of their setup, not a test of the data they return. An endpoint already used by a source is not suggested again.

Before you add your first source, Who your users are can show up to three ready suggestions. Once you have a source, Suggested sources lists the unused candidates, with ready ones first. Some ready choices are marked Suggested for you. Locked choices show why they cannot be used yet. Review setup appears only if you also have permission to manage integrations; otherwise ask someone with that permission to fix the problem. People who can manage user sources can still use ready choices.

1. Read the endpoint name and Look up by.
2. If it is locked, choose Review setup and correct the stated problem before returning. The link opens the connection settings for missing or unreadable access details or a disabled connection, and the endpoint settings for other problems.
3. For a ready endpoint, choose Use this. It opens the add form with that endpoint selected; it does not save a source yet.
4. Review the name and response mapping, then finish the steps below.

Ask your connected agent

Under Let your connected agent set it up, use the offered agent button. If you still need to connect an agent or allow changes in this workspace, follow the setup link first. See connecting your own agent.

1. Ask the agent to prepare a user source for your business system. If a new connection or endpoint is needed, finish the activation steps it hands you first. Both must be enabled before the agent can add the source.
2. Review its source name, response mapping and account-holder declaration in omotto. The agent’s new source starts switched off, with typed-detail lookups off too.
3. Turn Enabled on only after reviewing the setup.
4. Run Try it yourself with a known example.

The connected agent cannot turn a source on, enable Also look up details people type (unproven), or run Try it. Once a source is on, changing its mapping or account-holder declaration also stays in the app. The agent gives you a link to finish those steps yourself.

Add a Custom API user source

1. Under Who your users are, choose Add a source.
2. Enter a Source name you will recognise, such as “Student accounts”.
3. Choose the Custom API endpoint.
4. Set Response mapping (JSON) to match the actual reply from your system. The advanced section below explains this field.
5. Choose Add source.
6. Review the three switches on the new source card.
7. Use Try it to check a known example.

Cancel closes the form without adding the source. The endpoint is chosen at creation; the existing source card has no endpoint replacement selector. To use a different endpoint, add a replacement source and review anything that depends on the old one before deleting it.

Try it: test a lookup without verifying a customer

Try it calls the live endpoint, not a simulated reply. Use a test account you are authorised to look up. The source must be enabled and available.

1. Under Try it, choose the User source.
2. Check Look up by on its source card. It is read-only and comes from the selected endpoint.
3. Enter a valid value in Phone or Email, as offered. Before a source is selected, the field can show Phone or email.
4. Choose Run lookup.
5. Read Transport and Membership verdict separately.

Result	What it tells you
Transport	Whether the endpoint returned a response, and its response status. A successful response alone is not a membership match.
Match	The reply meets your mapping’s positive-match rule. It does not verify the person who supplied the test value.
No match	The reply did not meet the rule, such as an empty user list or a nonmatching membership value.
Ambiguous	Several records were returned; a single user could not be selected. Make the lookup more precise in your system.
Unavailable	The source could not provide a usable answer. Check the source, connection and reply format. Do not interpret it as “not a member”.

When available, the result also shows Provider user id, Role values seen and Contact on file (masked). A contact shown there has not been verified by the test.

The test never verifies anyone, saves a customer match, or saves a response sample. It retains only reported role values. It can run while the unproven-lookups switch is off because it does not accept a match on a customer’s behalf. Switching sources or reloading clears the displayed result; it is not a saved customer record.

Settings

Reuse a reported role as a label

On a skill’s verification line, Make this a label… opens a new label with the selected source and reported role already filled into its rule. It does not create a label automatically. Review and save the label, then choose it in Who is this for wherever needed. Existing source/role proof settings remain independent.

How people prove who they are: always-on methods

Under How people prove who they are, both methods show Always on. They are information rows, not switches.

Method	What it means in omotto	Default
WhatsApp number	omotto can use an authenticated number supplied by the WhatsApp channel as proof of that number. A number merely typed in a message is not the same evidence.	Always on.
Code to phone or email	Successfully completing a verification code proves control of the destination phone number or email address.	Always on.

“Always on” means the method is available. It does not mean every person has already been verified, or that omotto automatically sends a code to everyone. Neither method by itself proves membership in your business’s system.

You do not need a user source just to have these proof methods. Add a source when you need to distinguish a person who has proved their contact detail from someone who also has an account in your system.

Store account sign-in settings

Setting	What it does	Default
Count signed-in store customers as verified	Trusts a current, confirmed Shopify session on this website line. Turning it on needs the Shopify permission, a connected store, a successful storefront check and your confirmation. Turning it off remains possible if the store or line is in error.	Off.
Offer store sign-in in the chat	Allows the sign-in button when its other conditions are met. Appears while line trust is on; changing it does not change trust.	On.

These switches save automatically. Check the save status in the top bar. Storefront and customer-account messages are read-only status, not switches. Customer accounts: unknown means omotto has not confirmed the current store’s account settings.

Custom API user source settings

Setting	What it does	Starting value for a source added on this page
Source name	Names this source on the page and in the tester. Renaming it does not turn a customer into a member.	The name you enter; required.
Custom API endpoint	Chooses the operation that checks your system.	No selection; required when adding.
Response mapping (JSON)	Defines which returned fields count as a match, a user id, roles and an optional contact detail.	The form starts with records_path: "users", id_path: "id" and role_paths: ["roles"]. This is a starter, not a mapping inferred from your system.
Enabled	Allows this source to run and its eligible matches to be used. Turning it off makes its matches unavailable to checks that require it.	On after Add source succeeds.
Also look up details people type (unproven)	Allows unproven lookup results to be accepted as possible membership matches. It does not prove who is speaking.	Off.
The phone/email we look up by is the person’s own account login or contact	Declares that the lookup detail belongs to the account holder, not merely to someone mentioned on their record. With this on, a match for a proven detail can establish membership for that person. With it off, the match remains a possible association, even if the contact detail itself was proven.	On. Check that this is true for your system.

The name and switches save automatically. Check the save status at the top of the page. Creation and mapping changes use explicit buttons: Add source, or Edit mapping → Save mapping. Cancel leaves the saved mapping unchanged.

The disclosure risk of unproven details

Leave Also look up details people type (unproven) off unless you intend to allow this use. Someone could type another person’s email or phone number. A different response to a match could reveal that this person has an account with your business.

A match for an unproven detail is not identity verification. It must not be treated as proof that the person in the chat owns the matched account. This page configures and tests sources; turning on the switch is not a guarantee that the bot will automatically look up every detail typed in a chat.

When the account-holder declaration should be off

Suppose a student record contains a parent’s phone, or an order contains a gift recipient’s email. Finding that record does not necessarily make the person controlling that contact detail the student or account holder. Turn off The phone/email we look up by is the person’s own account login or contact when your source works that way. Do not leave it on simply to obtain a stronger match.

Advanced setup: Response mapping (JSON)

This section is for the person connecting your business system. JSON is the structured reply format used by the connection. You do not need to write it to understand the everyday settings. Start with Custom API connections if you have not prepared the connection yet.

The endpoint’s request method does not decide whether it is read-only; a POST lookup is allowed when Performs a real action is off and the operation only reads information.

The mapping reads exact fields and values. It does not interpret a sentence such as “this is an active student”, and an endpoint’s free-text response instructions do not replace this mapping.

Option 1: a list of user records

For a reply shaped like this:

{
  "users": [
    { "id": "member-123", "roles": ["student"], "email": "person@example.com" }
  ]
}

use:

{
  "records_path": "users",
  "id_path": "id",
  "role_paths": ["roles"],
  "contact_path": "email",
  "contact_kind": "email"
}

• records_path points to the list. For a nested reply, it could be data.users.
• id_path points to the user’s id inside each record. It is required with records_path.
• Exactly one record with a usable, nonblank text or integer id produces Match.
• An empty list produces No match. One record without a usable id also produces No match.
• More than one returned record produces Ambiguous. omotto does not choose one for you.
• A missing list or a value that is not a list produces Unavailable.

Option 2: one explicit membership value

If your system returns a direct answer, use predicate instead of records_path:

{
  "predicate": { "path": "membership.active", "equals": true },
  "id_path": "user.id",
  "role_paths": ["user.roles"]
}

The value must match exactly, including its type. The boolean true is not the text "true". The allowed comparison values are true, a nonempty string or an integer; not false, a list or an object. A different value, including a missing field, produces No match.

Here, id_path, role paths and contact paths start from the whole reply, not from a record in a list. id_path is optional in this form. Without it, a positive result uses the lookup phone or email as the returned user id. If you supply an id path, it must return a usable id for a match.

Other mapping fields

Field	Meaning	Default if omitted
role_paths	A list of paths to role values. A path may return one value or a list. Accepted text keeps its case and Hebrew characters; integers become text. omotto does not translate these values into its own roles. See the limits below.	No roles reported.
contact_path	An optional path to the contact detail held by your system. In Try it, that detail is shown partly hidden. It is not proof of control.	No contact detail.
contact_kind	Required with contact_path: use phone or email. Do not supply it without a contact path.	No contact kind.

Use exactly one of records_path and predicate. Paths use dots for nested fields; a specific list position such as users[0].id is supported, but a wildcard such as [*] is not. Unknown mapping fields are rejected.

The reply must be valid JSON and the request must succeed. A failed request or unreadable reply is Unavailable, not evidence that someone is a non-member.

Role values must be nonblank text or integers. Blank text, booleans, objects and other value types are discarded. Text longer than 100 characters, or containing a null character (\u0000), is discarded too. These limits apply even when the lookup returns Match.

Role values seen

Role values seen keeps up to 200 distinct accepted role values this source has returned, including during tests. Once it reaches 200, new distinct values are not added to this history. This cap limits the history list, not whether a lookup can return Match. It starts with No role values reported yet.

These are values from your business system, not omotto team roles or permissions. They are not an editable list here, and seeing a role in this list does not prove that a particular customer currently holds it. Adding a source or seeing a role does not by itself change an action’s access requirements.

Choose who may use an action

In the Handbook, open the skill’s rule under What [assistant name] does when…, then Who is this for. Inspect its Required verification line. Skills that are off remain listed, but their verification controls are read-only. For Appointments, use Go to Booking to edit exception approvers; the skill’s rule shows that group but does not edit it.

Adding a disabled source does not change an action’s access rules. Enabling a source can affect requirements set to Any provider, as explained above. In a skill’s verification controls or a Custom API operation, choose the requirement deliberately:

Choice	What the customer needs
Anyone	No identity or membership prerequisite from this setting. Other action rules still apply.
Resource verified	Proof tied to the relevant order or record. This is separate from membership; a Custom API chat operation currently needs identity-level proof for this choice.
Verified	Current qualifying proof of control, such as a completed code. A verified person need not have an account in your system.
Recognized	A current account match. This can include someone who merely typed a matching phone or email: it is not proof that they own the account.
Verified user	Both qualifying verification and a current account match tied to that customer. For Shopify, a trusted current store sign-in can provide the session-bound account link without verifying its phone or email.

For Recognized or Verified user, Provider selects a source. Any provider allows an eligible match from any source; naming one does not fall back to another. With a named source, Roles (any of) can restrict access to one or more role values that source has actually reported. The same current account match must supply the role; roles from different accounts are not combined. Shopify sources have no role values.

Membership controls can be unavailable during rollout. There is no switch on this page to release them; ask support if you need them. Existing saved membership requirements remain enforced even while new changes are disabled. Changing a sibling setting does not remove the saved requirement.

Details offered in chat and codes to a contact on file

When you allow unproven lookups, the bot can look up a phone or email the customer offers. A possible match still does not verify them. Where a code route is available, the bot sees a partly hidden contact on file, not the full destination. A changed destination must be offered again rather than silently sending a code somewhere else. Successful code verification proves control of its destination; it is not, by itself, membership in your system.

Matched profiles on the customer page

Accounts in your systems on a customer profile can show the source, match status, roles and other matched profiles. Staff with identity-decision permission can choose Yes, same person after reviewing the listed profiles. This links their histories; it does not verify their contact details. See reviewing profile matches before confirming.

What happens when…

A customer signs out or someone else signs in on the same device

Once the chat detects sign-out or a different store account, it starts a fresh conversation instead of showing the earlier account’s conversation. The previous customer’s profile keeps its saved store-account link. Loading a new page holds earlier messages until the check finishes; returning to the same open page keeps the conversation visible while new sends and live updates wait. It also renews periodically and before a send when renewal is due; focusing the chat alone does not start another check. This is not instant detection of every store sign-in change.

An earlier check that finishes late cannot restore the old store account after a newer check has replaced it, even if it came from another tab or no first message had yet been sent. This does not merge customer profiles across browsers or devices.

New text and files selected during the check stay local while the page remains open. They can continue under the safely confirmed or fresh chat identity; earlier account history and earlier uploaded attachment references do not move with them. A message already sent with an uncertain result is not automatically sent again as the new customer. A connection problem can delay recovery beyond the sign-in check; this is not offline delivery. See website chat recovery.

Your app proxy path was renamed in Shopify

The app proxy is the route Shopify uses to pass this check to omotto. Renaming that route is not supported by omotto. Restore the original route with your store maintainer or contact support. Verification codes remain available, but do not restore a previous account’s conversation after a sign-in boundary. Do not turn off an action’s verification requirement to work around the missing check.

A customer completes verification

Recording verification can start background lookups for the customer’s verified phone or email. Only enabled, available sources that support that type of detail can run. A recent, still-valid result may be reused rather than calling your system again.

You do not need to run Try it first. These verified-detail lookups can run while Also look up details people type (unproven) is off. That switch concerns unproven details, not this automatic verified-detail lookup.

A verified customer has no linked store account yet

If an action needs a Shopify user match but the verified customer has no linked store account yet, omotto makes one automatic background check using their verified phone or email. The action waits for that check, then is offered again. If no account can be linked, the customer still does not meet the requirement; the check does not grant permission by itself. A failed check does not mean they should keep verifying the same detail.

A WhatsApp customer has no phone number available

WhatsApp does not always share a phone number with omotto. A conversation can have proof of its WhatsApp account identity without a verified phone number available for a phone-based source.

Always on does not guarantee a usable phone lookup. The customer may still need to prove control of a phone number or email separately. A WhatsApp account identity alone cannot supply the phone or email that the source needs.

You add a source for existing customers

Adding a source does not start a background check of all existing customers. It also does not turn past Try it results into saved customer matches.

You disable, edit or delete a Custom API source

• Turn Enabled off to stop using a source without deleting its setup. Its old matches no longer satisfy checks that require that source.
• Review and retest after changing the mapping, switches or connected operation. Old matches from the earlier setup are not carried forward as permission under the new setup.
• Choose Delete source, then confirm, to remove it. Its saved matches and reported role values are removed too. Actions requiring that source no longer accept its matches. Deleting it does not delete the customer’s phone/email proof or remove the external account from your business system.

Troubleshooting

• An endpoint cannot be selected: read the explanation beside it. Check that the endpoint and connection are enabled, it is read-only, and it has exactly one supported identity input with no required conversation input.
• The source says its endpoint configuration changed: review the endpoint, choose Edit mapping, check the mapping and choose Save mapping, then test again.
• A Custom API source was disabled after connection or endpoint edits: correct the displayed problem, then turn Enabled back on. Fixing the connection alone does not automatically re-enable the source.
• Credentials cannot be read: review the connection’s access details with the person who maintains it. A connection that uses authentication needs saved access details; only a connection without authentication can leave them blank. Changing the connection’s sign-in type clears its old access details, so enter replacements before enabling the source again.
• The test rejects the identifier: enter only one phone number or email address, matching Look up by. For a phone number, use the full international form including its country code.
• A known member returns No match: check the returned record and exact mapping, not just the response status. A verification code cannot fix a wrong membership mapping.
• Ambiguous or Unavailable: resolve the data or connection problem before relying on the source. If the endpoint definition is incomplete, no lookup request is sent. Open its endpoint editor and correct the input fields listed in the problems banner. Do not weaken identity checks simply to make the result pass.
• A save fails: correct the field error and check the top-of-page save status before leaving.

If the connection and mapping look correct but lookups still fail, contact omotto support. Share the source name, the displayed error and when it occurred. Do not send passwords, access secrets or unnecessary customer details.

Related

• Who is this for: audiences and verification

• Verification levels, recognition and customer names

• Customer profiles

• Linking customer profiles

• Connecting Shopify

• Custom API connections

• Endpoint inputs and safety

• Permissions