zpoint/vibe-seller/amazon-fba-inbound

Amazon FBA inbound — Send to Amazon, end to end

Creating an inbound shipment, quoting it, confirming it, printing box labels, and voiding one. Covers both the ordinary path (your own carrier or an Amazon-partnered domestic carrier) and the cross-border SEND programme, which is browser-only.

Load amazon-shared first — it owns marketplace TLDs, the sign-in challenge loop, and the Ziniao/OTP/passkey rules. This skill assumes you are already signed in.

0. Why a browser at all

For most inbound work an API exists. For SEND it does not, and that is worth knowing before you look for one:

• GET /inbound/fba/2024-03-20/inboundPlans/{id} on a SEND plan answers

400 BadRequest: GetInboundPlan is not supported for the cross border Seller Export and Delivery program

• listInboundPlans omits SEND plans entirely
• a plan you create through the API is an ordinary FBA plan, so

listTransportationOptions only ever offers USE_YOUR_OWN_CARRIER — no partnered option appears

• the old v0 partnered flow (/shipments/{id}/transport) answers

400 This API is deprecated

The trap: the SEND partners are in the option list

The carriers Amazon names as its SEND partners do come back from listTransportationOptions, by carrier.alphaCode. Picking one does not book a SEND shipment — it books that company as a carrier you arranged. Same haulier, different product, and the difference is everything: no Amazon-arranged freight, no Amazon-issued tracking, no partnered price, and the shipment then waits on you for pallet or tracking details.

Verified end to end on a live account: confirming a SEND partner's USE_YOUR_OWN_CARRIER option produced a shipment with freightInformation: null and no quote — Amazon arranged and priced nothing.

The shipment's name tells you nothing about which one you have. That API-confirmed non-SEND shipment was auto-named FBA STA (…), and a genuine SEND shipment booked through the portal on the same account hours later was also named FBA STA (…) — while older genuine SEND shipments there read FBA SEA (…). STA is just "Send To Amazon", and the SEA/STA difference is naming history, not product. Reading the name as evidence is how a real SEND booking gets mistaken for the trap.

Litmus test, and it is the only reliable one: call getInboundPlan on the plan. A SEND plan is refused by name — GetInboundPlan is not supported for the cross border Seller Export and Delivery program — and an ordinary one reads back. listInboundPlans agrees: a SEND plan appears under no status (ACTIVE, SHIPPED, VOIDED are the only ones it accepts), so a confirmed plan you cannot find in any of them is a SEND plan. It also tells you when the difference is decided — the plan is one kind or the other from creation, so no choice at the transport step converts it.

What a genuine portal-booked SEND shipment reads on Step 3, for comparison: Carrier: Amazon Partnered (<partner>), Shipping mode: Ocean Shipping - LCL, Amazon partnered carrier fees: AED <amount>. An Amazon-partnered fee and a shipping mode are the positive signal; freightInformation: null is the negative one.

So: if the task wants SEND, use the portal. If it wants one of those carriers as your own forwarder, the API is fine — just don't confuse the two, and say in your report which one you booked.

Amazon has confirmed the same gap for the sibling AGL programme (amzn/selling-partner-api-models issue 4419: "We don't support Amazon Global Logistics Program via the new FBA Inbound v2024 APIs as of now."). So for SEND the portal is the only interface, and this skill is how to drive it.

1. Confirm the account BEFORE you click anything

The first words of document.body.innerText are the account nickname and the marketplace:

<account-nickname> <Marketplace Name> New Seller Central EN Help ...

Read them and compare against the task. A browser profile's name is not evidence of the account it holds — profiles get renamed, and a profile called after one brand routinely holds another. Creating a shipment in the wrong account is not a mistake you can take back, so if the task named an account and the page shows a different one, stop and say so.

window.ue_mid is the marketplace id (e.g. A2VIGQ35RCS4UG), not a merchant id — do not use it as an account check.

2. The wizard

The Supply-chain workspace (NGS drawer) now lists three sibling links: Send to Amazon (/fba/sendtoamazon), Send to AWD and Move from AWD (Amazon Warehousing Distribution). This skill is only about the first; don't follow an AWD link by mistake when the task says FBA.

Step 1 and Step 2 are two different pages, and confusing them wastes a run — Step 2 cannot be reached until Step 1 is clean:

Step 1  …/fba/sendtoamazon/confirm_content_step?wf=<workflowId>    choose inventory
Step 2  …/fba/sendtoamazon/confirm_shipping_step?wf=<workflowId>   quote + confirm

An in-progress workflow is resumable at either URL; &preselected=<code> appears once a carrier has been chosen. Four H4 steps:

Once packed, Step 2 restates the scope — SKUs: N Units: N Ship from: …. Check it against the task there; it is cheaper than discovering a mismatch after a confirmation.

Step 1 — choose inventory (verified live 2026-08-12, sellercentral.amazon.ae)

Two tabs, All FBA SKUs and SKUs ready to send (N). The table is SKU details · Packing details · Information/action · Quantity to send, and a row reads:

<listing title>
SKU: <your-msku>       ASIN: <asin>    FBA Storage Type: Standard-size
Product Category:       Prep not required   Unit labeling: By seller - Print SKU labels
More inputs

• Packing details is a kat-dropdown offering Individual units or

Create new case pack template.

• A selected row carries two number fields plus that dropdown:

kat-input[name="numOfUnits"] (label Units) and kat-input[name="numOfBoxes"] (label Boxes). A Bulk edit panel at the top of the table has its own pair with the same labels — match by bounding-box y against your row, or you will be typing into the bulk panel.

The recipe that works, driven by hand on 2026-08-12

Three agent runs failed on this step; ten minutes of driving it directly settled it. Per SKU, in this order:

1. `Start new` first, unless you were handed a workflow id — see above. This

is worth its own numbered step because it is skipped so easily: the workflow you land on can be weeks old and already hold staged SKUs. On 2026-08-13 a visit to confirm_content_step landed on STA (27/07/2026, 10:14 AM) with SKUs ready to send: 3 (390 units) on it, and editing began before anyone noticed. Read the footer and the `Current workflow` label before your first click; a non-zero count is somebody else's work.

1. Find the row. The table paginates (25 a page), so the SKU you want may not

be on the first one. Match the row by its SKU: … text and work from that element's bounding box.

1. Set the product category and press `Save` (see below) — before the

quantity, because committing the row locks Step 1.

1. Type the quantity into that row's `Units` field. Coordinate-click it, then

type_text. No .value (below).

1. Click that row's own `Ready to pack` button. It does not exist until a

quantity is entered, and it appears inside the row, to the right — there is no page-level equivalent, and this is the click that commits the row.

1. Read the footer: SKUs ready to send: 1 (10 units). The tab label

(SKUs ready to send (1)) moves with it. That is the page confirming it took the number.

No checkbox is required — the row's tick box stays unticked through all of this; entering a quantity is what activates the row. And a SKU that already reads Product Category: General needs nothing doing to it; only the rows showing ⚠ Product category required do.

Type into these fields. Never assign .value.

Every `kat-input` on this page is a web component whose real `<input>` lives in a shadow root — the same trap §3 records for the ship date, and it applies to every quantity here. Assigning .value on the element, or reaching through to the inner input with React's "native setter", tells Katal nothing: the field may even show your digits while the app never hears about them.

The footer is the only proof. SKUs ready to send: N (N units) is the page saying it accepted the number. If it still reads 0 (0 units), the number did not land, however convincing the input looks — and a reload will show the row empty, because the server was never told.

Burned on 2026-08-12: one run spent ~70 steps and 25 minutes on a single quantity, trying element .value, the native-setter trick, triple-click plus dispatchEvent, and the bulk-edit panel. All of it read back fine locally and none of it persisted. Do it the way a person does — coordinate-click the field, then type_text real key events — and read the footer to confirm.

• Product Category / Prep / Unit labeling appear only once a row is

selected.

What a row still owes you is a `kat-link`, one per requirement — this is the part that is easy to hunt for in the wrong place:

`More inputs` is not where these live. That kat-expander has no slotted content — opening it and looking for a category dropdown finds nothing, and document.querySelectorAll('kat-dropdown') on this page only ever answers the per-row Individual units control. Click the link whose label names what is missing. The row's own text shows the current value (Product Category: General), so the label says "required" while the text shows what it holds — do not read the visible word as proof it is set.

Match the link to the row that names your SKU — every selected row has its own copy, so "click the Product category required link" in document order opens the modal for whichever SKU happens to come first. Find the element whose text is your MSKU, take its bounding box, then take the link on that row (nearest by y), the same way the Actions column has to be matched on the Shipments page.

The category modal is .packing-template-modal, titled Select Product Category, and its header restates the row it belongs to — SKU: …, ASIN: …, FBA Storage Type: …. Read that header before filling anything in; it is the cheapest possible check that you opened the right row's modal.

• The foot of the page totals it and gates the step:

SKUs ready to send: 3 (150 units)      Total prep and labelling fees: AED 0.00
Please review SKUs with errors or unconfirmed SKUs
Workflow ID: wf…    Void this workflow    Created: …

• **The advance control's label depends on how far the rows have got, so read

what is on the page instead of reaching for a fixed one.** With rows selected but not yet confirmed it is Ready to pack plus a disabled Confirm and continue; once they are confirmed the page offers Pack individual units (also disabled until the rows are clean). Both observed on 2026-08-12, on two workflows of the same account.

• Whichever it is, it stays disabled while that review line shows, so a

selected SKU carrying an unmet requirement is what stops the whole run — not anything on Step 2.

The Product Category gate — an empty field here surfaces as a Step 2 error