Noon Integration – Feature & Process Guide
Noon is one marketplace family covered by two structurally different integration models in Pentagon Connect, and both also cover the related Namshi storefront through the same code path. Sellers can be on either or both models at once: a legacy model where Noon fulfils the order itself and data moves as batch files, or an API-based model ("FBP") where the seller's own warehouse fulfils the order and the integration talks to Noon close to real time. Support needs to know which model a given seller is on before troubleshooting, since expected behaviour differs significantly between the two.
Scope note: the source documentation for this integration is explicit that its first version ("v1") covers order management and stock/price updates only — creating or updating product listings on Noon or Namshi is not part of this integration, and there is no flow for pushing a new listing. Since that scope was set, Noon has also run a "partner migration" (mid-2026) that changed underlying request and response formats, and cancellation/returns handling for the merchant-fulfilment model were only added as recently as September 2026. Some behaviour may have moved on further than the source material reflects, and a few details are flagged there as unconfirmed.
Quick Reference
Product Management
| Capability | Supported | Notes |
|---|---|---|
| Create new product listings | No | Not supported — v1 scope excludes listing creation |
| Update product content (title, description, images, attributes) | No | Not supported — v1 scope excludes listing creation |
| Update price on an existing listing | Yes | Available on both the legacy file-based model and the API model |
| Update stock/quantity on an existing listing | Yes | Available on both models; API model is capped at 1,000 SKUs per update |
| Pause/deactivate a listing | Not documented | No mention of a pause/deactivate flow in the current source material |
Pricing & Stock
| Capability | Supported | Notes |
|---|---|---|
| Price updates | Yes | Via API (Noon/Namshi) or CSV file, depending on the seller's model |
| Automatic discount/RRP-based pricing | Yes | Legacy file model only — sends a sale price alongside a valid promo date window |
| Bulk stock updates | Yes | API model is capped at 1,000 SKUs per call; larger updates are split automatically |
| Confirmation that Noon applied a price update | No | Legacy file model is one-way — Noon gives no acknowledgment either way |
Orders & Fulfilment
| Capability | Supported | Notes |
|---|---|---|
| Automatic order retrieval | Yes | API model: near real time. Legacy model: batch file of orders already fulfilled by Noon |
| Ship orders (tracking) | Yes | API model only — legacy orders arrive pre-shipped by Noon, so there is no shipping step for them |
| Multiple tracking numbers per shipment | Yes | API model only |
| Real courier/carrier selection | No | Carrier is a fixed marketplace label, not a real courier list — see Carriers Supported below |
Cancellations & Returns
| Capability | Supported | Notes |
|---|---|---|
| Order cancellation | Yes | API model only, and only before the order ships — Noon treats a shipped item as final |
| Full/partial refund | Yes | |
| Returns | Yes | API model: matched from a returned-item notification. Legacy model: handled via credit note files |
| Claims / incidents mechanism | No | Not documented in the current source material |
Product Management
Product listing creation and content updates are not supported by this integration. The source scope for Noon explicitly limits the first version to order management and stock/price — there is no flow for creating a new Noon or Namshi listing, or for updating an existing listing's title, description, images, category or other content. Any product content changes have to be made directly in Noon's own seller tools.
What is supported is keeping price and stock in sync on listings that already exist on Noon or Namshi. Depending on which model a seller is on, this runs either through a live API call (for sellers using merchant fulfilment, "FBP") or through a batch file exchange (for sellers on the legacy, Noon-fulfilled model). Both reach the same outcome — price/stock on an existing listing reflects what's in Pentagon Connect — but the mechanics and timing differ.
Pricing & Stock Sync
Stock updates are sent in batches of up to 1,000 SKUs per call on the API model; larger updates are automatically split into multiple calls. Stock is sent per seller account separately, even where two accounts share the same warehouse — this can mean the same stock figure is sent twice, which is a deliberate simplification rather than a fault.
Price updates differ slightly between the Noon and Namshi storefronts on the API model: Namshi rejects a strike-through/RRP price that is lower than the actual selling price, so that field is only sent when it is equal to or higher than the price; Noon accepts any RRP value, including one below the price.
On the legacy (file-based) model, pricing supports RRP-based discounting: when a valid promotional start and end date are set and the RRP is higher than the price, both the regular and sale price are sent together with the promo dates; otherwise, only the regular price is sent. This channel is one-way — Noon does not confirm whether a price update was received or applied, so a successful file upload is always treated as a success on our side, even if Noon silently rejects or ignores it.
Order Management
Getting orders
On the API (FBP) model, orders are picked up automatically as they happen: Noon notifies us whenever an order changes, and we then retrieve the order's full detail. Buyer name, city and region come from Noon; the rest of the shipping address is not provided by Noon for this integration and is filled with placeholder values.
On the legacy model, orders arrive already fulfilled — Noon exports a batch file of completed orders, and virtually all buyer/shipping information (name, address, phone, email, carrier) is a fixed placeholder rather than real customer data, since Noon has already shipped the order itself by the time we see it.
In both models, Noon does not send a quantity per order line — every unit ordered is listed as its own line, and Pentagon Connect reconstructs quantity by grouping matching lines for the same product and price. If the price differs across otherwise identical lines, they're kept as separate order lines rather than combined, which can occasionally affect how order quantities look in reporting.
Order information we store
For every order, Pentagon Connect stores the order status, currency and key dates, buyer contact details (subject to the placeholder caveats above), billing/shipping address, carrier label and tracking number, and per-line detail such as SKU, product, price, quantity and line status.
Shipping orders
Shipping only applies to the API (FBP) model — legacy orders arrive pre-shipped by Noon, so there is no shipping step to perform for them. On the API model, once an order is ready, tracking information is sent to Noon and the order is marked shipped; multiple tracking numbers can be attached to a single shipment. Unusually among the marketplaces Pentagon Connect supports, Noon does not require a tracking number to be present before a shipment is sent.
Cancellations
On the API model, cancellation is only possible before an order has shipped. Once a shipment has gone out for an item, Noon treats it as final and it cannot be reversed through this integration — it would need to be handled as a return instead. Partial cancellation of a multi-item order is supported; the rest of the order continues to fulfilment as normal.
On the legacy model, cancellations arrive as credit note files from Noon. Importantly, a cancellation on this model does not change the order's status to Cancelled — the order stays marked as Shipped regardless of whether the cancellation is partial or full. This is a deliberate rule matching how Noon itself represents these orders, and is a common source of confusion when comparing against other marketplaces.
Refunds & returns
On the API model, returns are handled through a dedicated post-shipment flow: Noon notifies us that a return has arrived, and we look up what it contains and match it back to the original order line. Each returned line becomes its own refund. On the legacy model, refunds arrive the same way as cancellations, via credit note files, and are recorded as completed refund payments against the order, full or partial depending on how many lines are covered.
Carriers Supported
Noon does not provide a real courier/carrier list for this integration. On the API model, the "carrier" recorded against a shipment is a fixed marketplace label — literally "Noon" or "Namshi" depending on which storefront the order came through — rather than an actual courier such as DHL or Aramex. The tracking number itself is the meaningful piece of information; the carrier field should not be read as naming a real delivery company. On the legacy model, carrier is likewise a fixed placeholder value rather than a real courier.
Known Limitations
- No listing creation or update. This integration's v1 scope explicitly excludes creating or updating Noon/Namshi listings — only price and stock updates to existing listings are supported. Any product content work has to happen directly in Noon's own seller tools.
- Possible drift since Noon's mid-2026 partner migration. Noon migrated its partner API in 2026, changing request/response formats, and cancellation/returns handling for the merchant-fulfilment model were only added as recently as September 2026. Actual behaviour may have moved on further than what's reflected in the source documentation, and a few field mappings — including the source for ship-by/delivery-by dates, and the exact response format for stock updates — are flagged there as unconfirmed against Noon's current documentation.
- Two incompatible order models coexist. A seller is either on the legacy, Noon-fulfilled batch-file model or the API-based merchant-fulfilment model — expected behaviour (shipping, cancellation, what data is available) is very different between them, so confirming which model a seller is on is the first troubleshooting step.
- Cancellation is pre-shipment only on the API model; once an item has shipped, Noon does not allow it to be cancelled through this integration.
- Legacy cancellations never change order status to Cancelled — affected orders remain marked Shipped by design.
- Legacy price updates are one-way and unconfirmed — Noon does not acknowledge receipt, so a successful file upload is always treated as applied even if Noon rejects it.
- No real courier/carrier data — carrier is a fixed "Noon"/"Namshi" label, not an actual delivery company.
- No documented claims/incident process for this integration, unlike some other marketplaces Pentagon Connect supports.
Source Materials
This guide was built from Pentagon Connect's internal Noon v1 technical scope documentation, covering both the legacy file-based integration and the newer API-based merchant-fulfilment model shared by Noon and Namshi.