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