What the chat can and cannot change
An unknown number gets nowhere. A known number gets exactly the permissions its user has. And the part that answers your questions has no permissions at all, by construction rather than by instruction.
Only a verified user on your account reaches any of this. Reading needs no permission. Anything that changes something needs the matching permission read from that user's real role, plus a confirmation sequence. The AI assistant runs with an empty permission set and is not in any action path.
- A number is resolved to a real user on your account before anything else happens. Unknown numbers go nowhere near your data.
- Permissions are the same ones the web uses, read from the same source. There is no separate WhatsApp permission list to keep in step.
- The assistant is read-only, enforced with an empty permission set rather than promised in a prompt.
- Every action confirms first, through taps on messages Robnu sent seconds earlier, on a short deadline.
- Claims never reach a marketplace from the chat at all. Capture produces a draft a person submits from the app.
The reasonable objection to running a shop from WhatsApp is that a chat is a loose, forwardable, easily mistyped thing, and a marketplace is not. That objection is right, and the answer to it is not reassurance. It is that the dangerous actions are behind the same permission checks as the web, behind a confirmation a stray message cannot produce, and that the conversational part of the product is incapable of acting rather than merely discouraged from it.
First, who is speaking
Before anything else, the number that sent the message is resolved to a real user on your account, either a verified user record or an approved link. A number that is not one of those does not reach your orders, your payouts or your assistant.
That resolution is what makes everything after it meaningful. Permissions are a property of the user, so they are only useful once Robnu knows which user this is.
It also means removing someone's access is the ordinary thing you would expect: you change the user, not a separate list of phone numbers hidden somewhere.
Then, what that person is allowed to do
Reading needs no special permission. Order counts, a parcel's status, handover OTPs, a label you already own, a question about a deduction: all of that is available to any resolved user.
Changing something needs the matching permission, read from that user's real roles using the same function the web buttons use. Starting a processing run needs orders:process. There is no second, WhatsApp-specific permission list that could drift out of step with the web one, which is the whole point of reading from the same source.
This is what makes a shared warehouse phone genuinely safe rather than nominally safe. Give the person holding it a role without orders:process and that phone can ask anything all day and start nothing. It is not a restricted mode of the chat, it is the same permission that greys out the button on the screen.
The corollary is worth saying too: if you hand the phone to someone with an owner role, it has an owner's abilities. The chat does not add permissions and it does not subtract them.
The assistant cannot act, and that is structural
The part of Robnu that answers questions in plain language runs with an empty permission set. Not a careful prompt, not a list of forbidden topics: no permissions.
Actions do not route through it. Processing, return receiving, claim capture and tax documents are reached by short exact phrases that go straight to ordinary code, and every branch of those flows is code. There is no step at which a model decides you meant to process, or which account you meant, or that your confirmation was close enough.
This separation is the single most important design decision on the whole surface. A system that can both converse and act will eventually act on something it misread, and on a marketplace that costs real orders and real money. Keeping the two apart means the worst a misread question can do is give you an unhelpful answer.
It also means the assistant's answers cannot drift from what you would see on a screen, because it is the same read-only assistant the app uses against the same data.
Then, did you actually mean it
Permission establishes that you may. Confirmation establishes that you meant to, now, for this.
Every action walks a short sequence: Robnu asks, you pick a scope by tapping a button on a message it sent seconds earlier, it tells you what it found, you confirm. The sequence is held together by stored state with a deadline of a few minutes.
A forwarded message cannot walk that sequence. Neither can a sentence that happens to contain an action word, nor a message you sent an hour ago and forgot about. The deadline matters as much as the taps: a half-finished confirmation should not still be live on your phone later in the day.
Underneath all of it, the actual enqueue applies its own refusals, which were not rewritten for WhatsApp. If a processing hold is on, if a run is already active, if the day's cutoff has passed, the chat gets the same refusal the screen would.
Permission, then confirmation
One establishes that you may, the other that you meant to, now, for this
The things the chat deliberately cannot do at all
Filing a claim to a marketplace. Capture happens in the chat and produces a draft; a person submits it from the app. The claim module does not import the filing code, and a test fails the build if a path to it ever appears.
Minting a label from a label request. Asking for a label serves one you already own and refuses anything that would accept an order or create a new one.
Confirming a late processing run. Past the pickup cutoff the chat relays the refusal rather than offering a yes anyway button, because that decision needs the order list in front of you.
Each of those is a case where the convenient behaviour and the correct behaviour differ, and the correct one was chosen. They are also the cases most likely to be misread as missing features, which is why they are listed here rather than left to be discovered.
The part of this Robnu does for you
Robnu reads your Amazon account and reconciles every settlement line back to the order that caused it, so a wrong deduction is visible the day it lands.
- Orders, returns, payouts and inventory synced
- Every settlement line matched to its order
- FBA units Amazon has not made good, listed
Where this sits in the rest of your Amazon operation
On Amazon, Robnu syncs your orders, returns, payouts and inventory, reconciles every settlement line back to the order that caused it, lists the FBA units Amazon's own ledger has not made good, flags a return that never came back before the SAFE-T window closes, and scans returns in at your dock. It reads your Amazon account rather than writing to it, so accepting orders and making labels run on AJIO and Meesho today. Related reading:
Sources & further reading
- Robnu, the product the behaviour described here is the product's own. The WhatsApp surface calls the same endpoints the screens do, with the same permissions, so anything you can check on a screen is the same fact. Read 2 November 2026.
- Meta, WhatsApp Business Platform onboarding Meta's own page. It states that the 24 hour customer service window applies to messages sent through the Cloud API, and that a window opens when a person messages a business already onboarded to it. That rule is why a reply can arrive as a template rather than as free text. Read 2 November 2026.
Not legal or tax advice. Amazon changes fees, windows and policies without notice, and the detailed style guides and account-health thresholds sit behind a Seller Central login, so any figure quoted here as convention is not Amazon-published. Check anything you plan to act on against your own Seller Central account first.
Questions sellers ask
They get exactly the permissions of the user that phone is registered to, no more. If that user cannot start a processing run on the web, they cannot start one from the chat either, because both read the same permission from the same source. If the phone belongs to an owner account, it has an owner's abilities, so treat it as you would a logged-in laptop.
It does not reach your data. Numbers are resolved to a verified user on your account or an approved link before anything else happens, and an unresolved number takes a different route entirely. Permissions are a property of the user, so knowing which user is speaking is the precondition for everything else.
No. It runs with an empty permission set, and the action flows do not route through it at all. Those are reached by short exact phrases that go straight to code, and every branch of them is code, so there is no point where a model decides what you meant. The worst a misread question can do is produce an unhelpful answer.
No. Every action requires a sequence of taps on messages Robnu sent seconds earlier, held together by stored state with a short deadline. A forwarded message cannot walk a state machine, and a stale half-finished confirmation expires rather than waiting on your phone.
Through their role, the same way you would on the web. There is no separate WhatsApp permission list. Reading needs nothing special, so a warehouse phone on a role without orders:process can ask for counts, OTPs and labels all day and still be unable to start a run.
No. Reads touch nothing. Processing confirms first and then applies the same refusals the web does. Claim capture reaches no marketplace at all, since it produces a draft a person submits from the app. Receiving a return records a fact at your own bench and is never sent to a marketplace.
Related seller guides
More on the operations, money and claims that decide whether a marketplace catalogue actually makes money.
Every Robnu WhatsApp Command, And What Each One Does
The short commands Robnu matches exactly, the modes they open, and the much larger set of things you can simply ask in a sentence. Including which ones change something and which only read.
Meesho orders stuck in pending: what it means and how to clear them
Blocked does not mean paused, the dispatch clock usually keeps running. The four causes, which two you can fix yourself, and what to document when you cannot.
Process Your Marketplace Orders From A WhatsApp Chat
Say process my orders in a WhatsApp chat, pick the account, confirm, and Robnu runs the real accept, label and manifest pipeline. Four gates stand between a tap and a live run, and the assistant is not one of them.
Download A Shipping Label From WhatsApp In One Message
Send an order number, an AWB or a time window and the label PDF arrives in the chat, built to your own label settings. This path only re-downloads a label you already own. It never accepts an order and never mints a new one.
Someone else created the ASIN for your product
Finding your product already has a page another seller built is normal and usually workable. What you can change, what you cannot, and when a new ASIN is the right answer.
Receive Returns By Sending Codes In A WhatsApp Chat
Say return scan, then send AWB after AWB as the parcels come off the van. Each one is marked received the moment it lands, and shows up everywhere a scan from the web dock does, reports included.
Unicommerce Alternatives in India: Honest Options by Seller Shape (2026)
What Unicommerce is genuinely good at, why sellers look elsewhere, and the real alternatives by seller shape. Only three order management products in this market publish a price you can compute.
How to Hide the Address on a Meesho Label (2026)
How to hide the buyer address on a Meesho label safely: why it matters for privacy and reuse, which courier fields you must never cover, safe masking methods, and the compliance line you should not cross.