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.

Troubleshooting

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.

Troubleshooting

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.

Troubleshooting

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.

Troubleshooting

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

WhatsApp errors

Reconnect a WhatsApp number

A WhatsApp number needs reconnecting when its credential stopped being accepted — see error 190 for what causes that. The sequence matters, because the wrong first step can make the number harder to recover. The order 1. Settings → Inboxes → the inbox → Configuration. Reconnect from here. For a number connected through the guided sign-up this re-runs it; for a manually connected number this is where you replace the token. 2. Account Health. Confirm the number now reports normally, and that the webhook is registered. 3. Send one test message from your own phone to the number, and check it appears in Conversations. 4. Retry what failed. Nothing re-sends by itself. What the refusals during reconnection mean | What you see | What it means | |---|---| | Failed to exchange code for access token | the guided sign-up did not complete. Start it again; do not paste a token as a workaround | | The access token does not have the required permissions | the authorisation was approved without everything WhatsApp needs. Re-run it and approve all of it | | Failed to fetch phone number information | Meta accepted the credential but would not describe the number. Usually transient; try again | | Channel already exists for this phone number | the number is connected somewhere else on this installation — see the number is already connected | | Reauthorization is not supported for this type of WhatsApp channel | this is not a Cloud API number. A number connected through another provider is reconnected through that provider's settings | The two things not to do Do not delete the inbox. It does not reconnect anything, it loses the inbox's settings and collaborators, and it can release the number from your Meta app — which turns a five-minute reconnection into a support case. Do not connect the number a second time as a new inbox. A number can only be connected once across the whole installation, so this fails, and the failure message is easy to mistake for something else. A worked example An inbox shows the reauthorization banner on Monday morning. The administrator opens Configuration, reconnects through the guided flow, approves the permissions, and checks Account Health — the number reports normally and the webhook is registered. A test message arrives. They then go through Friday's three failed replies and press Retry on each. Total time, about four minutes. Who can do this Administrators only. Configuration and Account Health are not open to agents, and no custom role permission covers inboxes — see roles and permissions. Limits - Messages that failed while the number was disconnected are not re-sent. Retry each one. - Incoming messages during the outage were still stored, which is why there is a queue to work through. - Lynomia Chat cannot tell you which permission was missing. Meta reports a refusal, not a diff. - A hand-made token will expire again. The guided sign-up is what stops this recurring. Related - Error 190 - The number is already connected - Nothing is arriving from WhatsApp - Connect a WhatsApp number - WhatsApp Business coexistence