An Account Is Not a Store
An account gives its owner dashboard access. It can contain sites with their own domains and settings. The catalogue, public key and integration secret belong to a particular site. Before making changes, check the domain displayed in Settings (/lk/settings) and beside the token.
Search and the consultant are enabled separately for each site. Having an account, a key or an installed module does not prove that both products are available. If the module says the consultant is not connected, enabling the storefront chat checkbox cannot fix that.
Which Credentials to Use
| Credential | Purpose | Handling |
|---|---|---|
Public key, represented by YOUR_PUBLIC_KEY in examples |
Identifies the site for the browser widget | Allowed in HTML; does not provide owner dashboard access |
Integration key, ik_… |
Site secret for server connections | Server or module settings only; never HTML or screenshots |
| Integration tokens | Separate server API tokens for a site | Treat each as a secret; issue and revoke separately |
| Password and recovery codes | Owner's dashboard login | Do not give them to the module or use them as API keys |
Tokens from the dedicated section have search and reindex permissions; the issuance form does not offer arbitrary permission selection. Do not automatically equate them with the Integration key: the issued token's format can differ. Use the credential required by your connection. For the module's Anmarto key field, use the site's ik_… secret rather than the public widget key.
Initial Setup
- Sign in as the owner and open Settings (
/lk/settings). If you started in Bitrix, complete email confirmation through the message you received. - Check the store domain. Do not copy another site's key, even when both sites have the same owner.
- Check the profile name and email. The email is also the login, so change it only to an address you can continue to access.
- Find Integration keys. Use the public key in widget code and store the secret key securely when it is issued.
- If the server API requires a separate token, go to Integration tokens and select Issue for … beside the intended domain. Copy the value immediately: it is not displayed again.
- Enter the server secret into the integration's designated setting. For Bitrix, check the accepted-key message and site domain.
- Run a small check: module connection, reference-product export and storefront search. Do not publish the key alongside the result.
- Protect login: in the dashboard login section, select Enable, add the QR code to a one-time-code application, enter the code and select Confirm.
Replacement and Revocation
Reissue the key replaces the Integration key: the old value stops working immediately. Before confirming, list the modules and scripts that use it. Save the newly issued secret, update those connections and verify them again. Reissuing is not a way to view an existing secret.
Issuing a separate API token does not revoke previous tokens. For a planned replacement, issue a new one, update the relevant client, verify operation and only then select Revoke for the old token. Revocation disables every connection using that particular value. If you suspect a leak, revoke the compromised secret without waiting, then restore connections with a new one.
Login and Troubleshooting
Two-factor protection starts only after code confirmation, not merely after displaying the QR code. Save recovery codes immediately: each works once. The dashboard shows how many remain; disabling protection requires the password. To change the password, enter the current password, the new password and its confirmation.
If the connection fails, check credential type, domain, revocation status and HTTPS access. A token's last-used information helps identify unused connections but does not replace module verification. In a support request, provide the domain, time and error message without the secret itself. Continue with Bitrix, embedding or troubleshooting.