One channel, one store

Two refusals stop you in the same place, on the same screen, at the same moment: you are connecting a channel and it will not save. They have nothing else in common. One is about who already has this number, and the other is about what your plan sells — and the remedies have nothing to do with each other.

So read the sentence rather than the situation. The sentence tells you which problem you have.

Which refusal you are looking at

The first is this page. The second is on it too, because people meet the two together. The third is a rule of its own, and for WhatsApp it already has a page: "Channel already exists for this phone number".

What a claim is

A claim is one record saying this channel identity belongs to this store and to no other. It holds four things: the channel type, the identity itself, the workspace that holds it, and the integration's own name for the store — a store id, which is how an operator can say which store has it.

Claims belong to the integration, not to you. Only an integration makes and releases them, through the Platform API. There is no claims page in settings, nothing in Lynomia Chat creates one, and nothing in Lynomia Chat removes one. Connecting a channel yourself does not reserve it, and there is no screen anywhere that lists who holds what.

Ten channel types carry an identity that can be claimed:

The website widget and the API channel are never refused by this rule. Their identifiers are minted by this installation, so they are unique already and there is nothing a second store could collide with.

What counts as the same channel

The claim is on the identity, not on what somebody typed.

• A phone number is reduced to its digits with a leading +. +965 2222 3333, 96522223333 and 0096522223333 are one number, and claiming any spelling claims all of them.
• No country is assumed. A number typed without its country code is a different identity. 22223333 is not +96522223333. Guessing a country would silently equate two numbers in two countries, so it is not guessed — and that means a claim made on a bare national number protects nothing.
• An email address is lowercased. Sales@Example.com and sales@example.com are one mailbox.
• An id the provider issued is compared exactly, letter for letter. PageABC and pageabc are two different pages here, because lowercasing a case-sensitive token would merge two channels that are genuinely different.

When the rule applies to you at all

It applies only while an integration holds your workspace — a workspace Store Syria arranged for you, or your own workspace after you connected it to Store Syria. A workspace no integration holds is subject to none of this. Connecting your own WhatsApp number conflicts with nobody, and this rule never says otherwise.

Two more boundaries, both of which you can rely on:

• The claim must belong to the same integration that holds you. Two integrations on one installation do not see or block each other.
• A claim your own workspace holds never blocks your own workspace. Connecting again what you already hold is allowed, and retrying a connection that half-failed is safe.

Where you meet it

The refusal arrives when the channel is saved, however you got there — the dashboard, a provider's sign-in callback, or the API. There is no earlier warning and no pre-check you can run.

It is checked on every save, not only when the channel is created. Editing a connected WhatsApp or SMS channel's phone number, or an email channel's address, onto an identity another store holds is refused in the same words. Connecting something unclaimed and then editing it to what you actually wanted does not work.

An edit that does not touch the identity is never refused by this rule. Renaming the inbox, rotating a credential or changing a forwarding address goes through, whatever other stores hold.

What you see is one sentence. The store holding the channel is named only in the answer the integration receives, never in yours. That is deliberate, for the same reason a WhatsApp number connected in another workspace is not named to you either: telling you would leak another merchant's setup.

When the refusal is a connection you no longer control

This is the common case — a number connected for a store you closed, sold, or set up before you took over. Nothing you can do inside Lynomia Chat resolves it, because nothing inside Lynomia Chat touches a claim.

• Ask Store Syria which store holds it. They can see the store id in the conflict; you cannot. Give them the number, mailbox or page exactly as you are entering it.
• That store releases the channel, from its own side. A released claim is kept as history rather than deleted, so who held a number in March still has an answer, and it stops blocking the moment it is released.
• Releasing the claim is not the whole job. The other store's inbox still exists, and for most channel types the installation's own uniqueness rule then refuses you instead. That inbox has to be removed too. Freeing a channel properly is two steps on two sides, and the second one is the one people forget.

Plan channel entitlements

The other refusal is commercial, and it is about the channel type rather than your particular number.

A plan either names no channel types at all, in which case it sells every one of them, or it names a list. A type that is not on the list is refused when the channel is created:

Your plan does not include the Whatsapp channel. Upgrade your plan to connect it.

Two things about that sentence:

• The channel is named by its internal key. It reads Whatsapp, Sms, Tiktok or Api rather than the name you would write. That is the channel type, not your inbox, and nothing about your inbox is wrong.
• It is checked only when a channel is created. An inbox you already have keeps working if that type later leaves your plan. You simply cannot add another.

An exception Lynomia has granted your account wins over the plan, in either direction — it can sell you a channel the plan withholds, or withhold one the plan sells. Plans, limits and what they stop covers all of this, and the inbox ceiling with it: being sold WhatsApp and having room for another inbox are two more separate questions, with two more separate refusals.

What it is not

• It is not the installation-wide uniqueness rule. A WhatsApp number, an email mailbox, a Telegram bot token, a LINE channel id, a Twilio number, an Instagram account and a TikTok business can each be connected once across the whole installation, in any workspace, integration or not. A Facebook page and a Twitter profile are the exception: those are unique per workspace, so two workspaces can hold the same page. That refusal is worded has already been taken. See "Channel already exists for this phone number" and reconnect a WhatsApp number.
• It is not the store rule. One store, one workspace is about the store-data connection, not about a channel — see Store Syria: common questions. A store and a channel are claimed separately and refused separately.
• It is not your inbox ceiling. That refusal names a number and tells you to upgrade.
• It says nothing about messages. A claim decides who may connect an identity. Whether a message then sends is the 24-hour window, template approval, consent and your messaging limit, none of which this touches.

Who can do this

Administrators connect and edit channels — see roles and permissions. Everything to do with a claim belongs to the integration and to the operator of the installation: there is no agent action, no administrator action and no setting. If you need to know who holds a channel, that is a request to Store Syria or to Lynomia support.

Limits

• You cannot see claims, and the refusal does not name the holder. No page, no list, no export. The refusal is the only signal you get.
• Connecting a channel does not claim it. Only the integration's own action does. So your numbers are not automatically protected against another store by the act of connecting them.
• Deleting the inbox does not release the claim. They are separate records, and nothing in Lynomia Chat writes to a claim.
• A claim can exist with no inbox behind it. An integration may reserve an identity before anything is connected, so a refusal does not prove there is a working inbox somewhere.
• Both refusals are shown in English, whatever language the dashboard is set to.
• Nothing warns you before either one. Neither the claim nor your plan's channel list is visible while you are filling the form in.

Related

• Set up an inbox
• Connect your first channel
• Plans, limits and what they stop
• "Channel already exists for this phone number"
• What the Store Syria integration gives you
• Store Syria: common questions
• Roles and permissions

If it does not work

"That channel is already connected to another store" and I have never connected this number. Another store on the same integration has. Ask Store Syria which one — the conflict names the store on their side, and only on their side.

I deleted the old inbox and it is still refused in the same words. Deleting an inbox does not release a claim. The claim is still active and only the integration can give it back.

The claim was released and now I get "has already been taken" instead. Two different rules, met in order. The claim no longer blocks you; the other workspace's inbox, which still has the identity, now does. That inbox has to go.

I was refused and I am the only store there is. Check the sentence again. Your plan does not include is your plan, not another store, and no amount of asking Store Syria will change it.

The refusal names "Whatsapp" and my inbox is called something else. The plan refusal names the channel type, in its internal spelling. It is not referring to your inbox.

I typed the number without its country code and it saved, then the real number was refused. Those are two different identities to this rule. Enter the number in international form, with its country code, everywhere.