Troubleshooting

When something is not working

Most reports fall into four causes. Working out which one you are looking at is faster than reading about the feature, and it is usually enough. | Cause | What it looks like | |---|---| | A role | the page or button is missing entirely, for you but not for a colleague | | A plan or an installation switch | the page is missing for everyone, including administrators | | Meta | WhatsApp refused something, and the product is reporting that refusal | | Configuration | the feature is there, you used it, and the result was not what you expected | Start with who you are More "it is broken" reports are a role than anything else. An agent sees only the inboxes they are a collaborator on, and no settings at all. A custom role sees only what it was granted, and the permission list is shorter than people assume — it has no entry for inboxes, channels, campaigns, WhatsApp templates, flows, automation rules or audiences. Roles and permissions has the exact list. If a colleague who is an administrator also cannot see it, stop looking at roles. It is a plan or an installation-level switch, and nothing in your account changes those. Then find your symptom | Symptom | First thing to check | Where it is explained | |---|---|---| | No WhatsApp messages are arriving | the inbox's Account Health tab | when WhatsApp does not work | | I cannot type a reply, only send a template | when the customer last wrote | the 24-hour window | | A template was rejected or paused | the rejection reason on the template | the template lifecycle | | A campaign says Completed but nobody got it | whether the template is still APPROVED | WhatsApp campaigns | | My template is missing from the campaign dropdown | its status, category and components | WhatsApp templates | | A conversation is not in my list | the status filter, then your inbox membership | work in the inbox | | An agent cannot see an inbox's conversations | the inbox's Collaborators tab | set up an inbox | | An automation rule did nothing | that the rule is switched on | automation rules | | A flow never started | that it is published, on a WhatsApp Cloud inbox | flow builder | | An import skipped every row | labels that do not exist, or missing country | import contacts | | An audience matches nobody | whether your labels are on contacts or conversations | labels or shared audiences? | | Orders are not showing beside a conversation | whether the contact matched a store customer | Customer 360 | | An order action I need is not offered | the per-platform table | what each platform supports | | My endpoint is not receiving events | that the URL is publicly reachable | webhooks | | I cannot find out who changed a setting | whether that action is audited at all | audit logs | What leaves a trail, and what does not Before you spend an hour looking for a log, this is what exists. | Area | What you can inspect afterwards | |---|---| | Campaigns | per-recipient outcomes, with a reason, where your installation has campaign analytics | | Flows | Sessions on the flow: where each run ended and why | | WhatsApp | the inbox's Account Health, and each failed message's own reason | | Configuration changes | audit logs, for the fourteen event types it covers | | Automation rules | nothing. There is no run history and no per-rule log in the product | | Webhooks | nothing. No delivery log, no retry, no replay | | Imports | the import's own result counts | Where the answer is "nothing", the practical approach is to reproduce the trigger deliberately and watch what happens, rather than to search for a record of the first time. Four things no amount of configuration fixes - Meta owns template verdicts, quality ratings, messaging limits and display-name decisions. The product reports them. It cannot appeal or override them. - Messages sent to a WhatsApp number while its webhook was missing are gone. There is no backfill. - Out-of-hours behaviour cannot be built with automation. There is no business-hours, time-of-day or working-hours condition. An inbox's own business hours and unavailable message are the tool for that — see set up an inbox. - Refunds and cancellations cannot be delegated to a custom role, on any platform. Who can do this Agents can see most symptoms but almost none of the causes: Account Health, inbox configuration, templates, campaigns, automation and audit logs are administrator-only. If you are an agent, your useful contribution is a precise symptom — which conversation, which number, what time — and then escalating. Related - When WhatsApp does not work - Roles and permissions · Set up an inbox - Audit logs · Webhooks - WhatsApp campaigns · Automation rules · Flow builder - What each platform supports

Your store needs to be reconnected

A store in this state has stopped working completely: order history does not load in a conversation, abandoned carts stop arriving, and order actions are unavailable. The product is not retrying in the background, because retrying with access the store has refused would not help. Only an administrator can fix it, and it takes one action: Settings → Commerce → the store → Reconnect. What the product is telling you | What you see | The code behind it | |---|---| | “This store needs to be reconnected” in Settings → Commerce | the store's status is needs_reauth | | “We could not reach your store” in a conversation panel | AUTH_INVALID | The status is durable: it was written the moment the store refused the access, and it stays until somebody reconnects. It is not a guess from a single failed request. Why it happens The reason differs per platform, and it is worth knowing because two of them can happen without anybody doing anything wrong. - WooCommerce — the API key was deleted, or its permissions were changed, in WordPress → WooCommerce → Settings → Advanced → REST API. This is the one that is usually deliberate: somebody tidied up keys. - Salla — the app was uninstalled or its authorization lapsed in the Salla dashboard. Reinstalling the app reconnects the store on its own; you do not need to create a new connection code unless the store is also gone from the list. - Zid — the authorization expired, or the app was removed. Zid also sometimes answers a rejected authorization with a redirect to its login page rather than a refusal, and the product treats that as a rejected authorization, which is the correct reading. - Shopify — the app was uninstalled from the store's admin, or the access it was granted was revoked. What is kept and what is removed Reconnecting does not start you from scratch, and disconnecting does not delete your history: - the store's access is removed when it moves to this state, and so is its cached data, which is why panels go blank rather than showing something stale; - conversations, contacts and your order-action history stay. They are Lynomia's own records, not the store's; - a store you disconnect keeps its row, so reconnecting the same store later reuses it rather than counting against your plan's store limit twice. If reconnecting does not hold If the store moves back into this state within minutes of reconnecting, the access you granted is not the access the product needs — it connected and then was refused on its first real request. That is a permissions problem rather than an authorization one: see Your store keys cannot do that.

Lynomia cannot reach your store

This is a connection problem, not an authorization one. The access is fine; the store did not answer in time, or did not answer at all. | What you see | The code behind it | What it means precisely | |---|---|---| | “Your store did not answer” | STORE_UNAVAILABLE | the connection failed, or the store returned a 5xx | | “Your store took too long to answer” | TIMEOUT | the request was sent and no answer arrived inside the limit | What the product does about it, without being asked - It waits a bounded amount of time. Three seconds to connect, eight seconds for an answer, and ten seconds for the whole body. A slow store costs one timeout, never a hung page. - It retries once, and only for a read. A dropped connection or a 502, 503 or 504 on a read is tried again once. A timeout is not retried, so a slow store cannot be made slower by us. An order action is never retried, because sending a refund twice is worse than reporting one failure. - It shows you what it already has. If the panel can serve cached order history it will, labelled with when it was last updated. A panel that says “last updated 40 minutes ago” is telling you the truth rather than pretending to be live. - It does not change the store's status. A store that cannot be reached stays active, because being temporarily unreachable is not the same as having lost its authorization. What to check, in order 1. Open the store yourself, in a browser, from a normal internet connection. If it is slow or down for you, it is slow or down for us. 2. WooCommerce only: check that the store is reachable from the public internet. A store behind a VPN, on a private network, or on a localhost address cannot be reached by anything outside it, and the product refuses to try — see The store address was refused. 3. Check your hosting for rate limiting or a firewall rule. A host that blocks or throttles unfamiliar traffic will refuse us consistently while a browser works, which is the pattern that looks most like a product bug and is not one. 4. Check whether it is only slow under load. A store that answers in twelve seconds is working, from its own point of view, and will time out here every time. That one needs the hosting fixed, not the connection. When it clears up Nothing needs to be done. The next successful request serves live data again, and the panel stops saying it is stale. There is no cache to clear by hand.

The store address was refused

This one is refused before any request leaves Lynomia, or as soon as the store answers with a redirect. It applies to WooCommerce, which is the only platform where you type an address — Salla, Zid and Shopify provide their own. | What you see | Why | |---|---| | “That address is not a store we can reach” | the host resolves to a private, loopback, link-local or metadata address | | “That address is not valid” | the address is not a usable https URL | | “That store redirected us somewhere else” | the store answered a request with a 3xx | The private-address rule is deliberate, and it protects you Every request to a store resolves the host first, refuses private, loopback, link-local and cloud-metadata addresses, and then pins the connection to the address it checked — so nothing can answer the check with a public address and then serve the request from somewhere internal. This is why http://localhost, http://192.168.x.x, http://10.x.x.x and a .local hostname are all refused. A store on your own machine or office network cannot be connected: it is not reachable from the internet, and an address that resolves to somewhere internal is exactly the shape of request this rule exists to refuse. Use the store's real public address, the one a customer would type. Redirects are never followed If your store answers on https://shop.example.com by redirecting to https://www.shop.example.com, the redirect is refused rather than followed, and you will see the redirect message. Enter the address the store actually serves from — the one you end up on after the redirect — and the problem goes away. Not following redirects is on purpose: a followed redirect means the next request goes to a host nobody checked. What to enter - the scheme: https. An http store can be connected only where an administrator of this installation has explicitly listed the host as a development store; - the host the store serves from, after any redirect; - no path: not /wp-json, not /wp-admin, not a trailing page. The product adds the API path itself. If the address is right and it is still refused Then it is not the address. A store that answers on the address you entered but refuses the request is a connection or a permissions problem — see Lynomia cannot reach your store and Your store keys cannot do that.

Your store keys cannot do that

A store can be connected, reachable and working — and still refuse something. Reading orders and changing them are different permissions on every platform, and Lynomia never quietly upgrades the access you granted: an administrator grants it deliberately or it stays as it is. | What you see | The code behind it | |---|---| | “Your store refused that” | PERMISSION_DENIED | | “These keys cannot change orders” | WRITE_ACCESS_DENIED | | “This store is not approved for customer data” | PROTECTED_DATA_NOT_APPROVED | | Order actions greyed out, with a reason | read_only_key or missing_scope | Reading and writing are different grants - WooCommerce — an API key is created as Read or Read/Write. A Read key is exactly right if you only want order history in conversations. Order actions need Read/Write, and the product will not pretend otherwise: it records read_only_key the first time a write is refused, and shows that as the reason the action is unavailable. To change it, create a new Read/Write key in WordPress → WooCommerce → Settings → Advanced → REST API and replace the keys in Settings → Commerce. An existing key's permissions cannot be raised in place. - Shopify — order actions need the write_orders scope. Without it the product records missing_scope and reports the action as unavailable rather than attempting it. Reconnecting the store re-requests the scopes. - Zid — the same shape: a store whose authorization does not include order management records missing_scope. - Salla — the Lynomia app is read-only by design. Order actions are not offered for Salla at all, which is a capability of the integration rather than a problem with your store. Shopify protected customer data Shopify requires an app to be approved before it may read customer names, emails and phone numbers. Until that approval is in place, a Shopify store connects and works for everything except customer details, and the product reports it as not approved rather than as a failure — because it is not one, and it is not something you can fix from your store. Order actions also have their own switch Separately from the keys, order actions are off by default per store. Settings → Commerce → the store → turn on order actions. Turning them on requires credentials that can already write, which is why the switch refuses with the same reason above if the keys are Read-only: an opt-in that silently does nothing would be worse than an honest refusal. What this is not If the store reads nothing at all, this is not your problem — see Your store needs to be reconnected (the access is gone) or Lynomia cannot reach your store (the store did not answer).

An order action did not apply

An order action — cancelling an order, changing its status, issuing a refund — is the only thing Lynomia writes to your store. Everything about how it behaves follows from one rule: a write is never sent twice. A duplicate refund is worse than a failure you can see. Every outcome, and what to do | What you see | The code | What actually happened | What to do | |---|---|---|---| | “The order changed while you were looking at it” | ORDER_CHANGED | somebody else changed the order between the panel loading and the action being sent | re-open the order and try again on the current state | | “That did not apply” | NOT_APPLIED | the store accepted the request and the order is provably unchanged | safe to try again | | “Your store declined the refund” | REFUND_DECLINED | the payment gateway refused, not the store | refund from the store's own admin, where the gateway's reason is visible | | “Your store refused that” | PROVIDER_REJECTED | the store rejected the action itself | check the order in the store's admin; it is usually in a state that does not allow it | | “That action is already running” | ACTION_IN_PROGRESS | the same action is in flight | wait; do not start a second | | “That amount is not valid” | INVALID_AMOUNT | the amount is outside what the order allows | check the order total and what has already been refunded | | “We do not know whether that applied” | an unknown outcome | the request was sent and the answer was lost | read the rest of this page | | “Order actions are turned off” | ACTIONS_DISABLED | the switch is off for this store | an administrator turns it on in Settings → Commerce | | “That action is not available for this store” | ACTION_UNAVAILABLE | the platform does not support it | nothing; it is a capability, not a fault | “We do not know” is an honest answer, not a bug If the request reached your store and the answer was lost — a timeout after sending, a dropped connection — then Lynomia genuinely cannot tell whether the action applied. It will not guess, and it will not send the action again to find out. What it does instead: 1. It reads the order back, a little later, and judges only by what the store says now. If the order is in the state the action asked for, the action succeeded. If it is provably in the state it started in, the action failed and is safe to retry. 2. If reading back cannot settle it, the action stays recorded as unknown, and the panel says so. 3. It never re-sends. An action that may have applied is not sent again by the product under any circumstances. If an action is sitting at unknown, open the order in your store's admin. That is the authoritative answer, and it takes a few seconds. Why actions are deliberate rather than convenient - they are off per store until an administrator turns them on; - they need credentials that can write — see Your store keys cannot do that; - they are checked against the order as the agent saw it, which is what produces ORDER_CHANGED rather than a surprise; - every one is recorded with who ran it and what the store answered. That is four opportunities for an action to be refused, and each refusal is a sentence rather than a silence.