Technical ceiling

Proven rule. Every body claim traces to a primary source with an accessed date. Official developer documentation outranks every blog. Blog-only claims are labelled and marked unverified. Anything I could not determine is parked in §4, not inferred.

Verdict

A third party can, in 2026, honestly promise a credentialed operator — not merely an advisor — on both marketplaces: create and edit listings, set price and stock, build campaigns, change bids, add negative keywords and pull Search Query Performance on amazon.ae and amazon.sa, and run catalogue, price, stock, offers and partner fulfilment on noon across AE/SA/EG — provided it registers as an SP-API public developer, an Amazon Ads API applicant and a noon Partner Integrator, and declares itself an automated Agent under Amazon's March 2026 BSA; what it cannot promise is Noon advertising, reading raw reviews or buyer conversations, cross-seller benchmarking, or any automation that drives a Seller Central browser session.

Headline: 006's ceiling is out of date

006:[C8] recorded the mid-2026 position as "exports in, recommendations out, human pushes the change," with Amazon Ads MCP "partner-only." Three of those four framings no longer survive contact with the primary documentation.

Two clarifications, because the distinction is load-bearing:

The crawler block and the API are different doors. Amazon still blocks AI crawlers — amazon.ae/robots.txt and amazon.sa/robots.txt each list ~101 user-agents, with ClaudeBot, Claude-User, Claude-SearchBot, GPTBot, ChatGPT-User, PerplexityBot, Google-Extended, xAI-Grok and Bytespider all carrying Disallow: / [A6-S28]. That closes the shopper-facing web. It says nothing about SP-API, which is a separate, credentialed, contractual door that has been open the whole time and got materially wider in 2025–26.

006 described practice; the brief asked for the ceiling. Practitioners start from hand exports because they are individual sellers who have not built an SP-API app, not because the API refuses to serve the data. For a company that registers as a developer, almost every file in those workflows has an API equivalent.

1. What we found

1.1 Amazon SP-API — access requirements

Registration is gated on corporate identity and a public website, not on revenue or an existing seller base. A pre-revenue startup with a registered company qualifies.

What Amazon actually asks for before registration [A6-S5]:

• company registration number and registered business address
• government-issued ID or passport
• recent bank or credit card statement
• use-case descriptions
• for restricted roles: security/compliance docs, data-handling docs, architecture, retention policies

Public developers additionally must supply a live website. Amazon's words: "you must share a website URL that is publicly available and provides details about the services that your application offers to Amazon sellers. Websites that are not accessible, are under construction, have a security warning, or are log-in only are not accepted" [A6-S4]. The website guidelines are prescriptive — HTTPS with a valid certificate, a privacy policy, a direct contact method, a displayed pricing structure, no unverified claims like "#1 app", and a product name that is not solely generic [A6-S6].

Two review paths [A6-S4]:

Restricted roles add an architecture review with the SP-API Solutions Architecture team, described as "a detailed explanation of data flows and protection controls for PII" that "can involve a demo through screen sharing" [A6-S4]. Amazon closes cases if you do not respond within five days [A6-S4].

Roles. There are 18. Four are restricted (PII): Direct-to-Consumer Shipping, Professional Services, Tax Invoicing, Tax Remittance [A6-S3]. None of the operations this Inquiry cares about needs a restricted role. Listings, pricing, inventory, reports, Brand Analytics, buyer messaging, solicitations and FBA inbound are all unrestricted. That is a significant de-risking: the heavy architecture review is avoidable by scope choice.

Public vs private. A public developer serves many sellers via OAuth and must list the app in the Selling Partner Appstore [A6-S4]. A private developer serves only its own organisation and gets a streamlined review, but a private seller application requires a Professional selling account [A6-S45]. For SHIO's own account, private is the fast path; for a product, public is mandatory.

1.2 Amazon Ads API — access requirements

Materially easier than SP-API, and this is the correction to 006.

Amazon's own words: "To use the Amazon Ads API, you must apply for access and be approved. Direct advertisers, partners, and integrators are all eligible to apply" [A6-S20]. Three steps: create a Login with Amazon client ("free to create, and no approval is required for this step"), apply for access, assign access to the LwA client [A6-S20]. Review takes up to one business day [A6-S20] [A6-S21].

Two application routes [A6-S21]:

One irreversible step to flag for the build: "Your LwA developer registration will be associated to your Amazon Ads API permissions in the next step... This association cannot be changed once it is set" [A6-S21].

Ads MCP is not partner-gated. Amazon's MCP getting-started says step 1 is "Use an existing LwA application and Amazon Developer account with access to the Amazon Ads API or complete the onboarding steps" [A6-S24]. Since a Direct Advertiser can self-apply in a day [A6-S21], the MCP server is reachable by any approved applicant. It has a dedicated EU endpoint, https://advertising-ai-eu.amazon.com/mcp, which is the one that serves AE and SA profiles [A6-S24] [A6-S19]. Amazon documents it as supporting Claude, ChatGPT, Kiro, Bedrock and AgentCore [A6-S23].

1.3 Marketplace coverage: .ae and .sa

Both APIs cover both marketplaces, at the EU endpoint.

Egypt is in scope for both too [A6-S1] [A6-S19], which matters because Noon's own API is documented for AE/SA/EG [A6-S36].

Where .ae/.sa fall out of scope — the real gaps. Region support is not feature support. Three concrete losses:

The Customer Feedback API is the painful one — see §1.5.

1.4 The March 2026 Agent Policy — the biggest change since 006

On 2026-02-17 Amazon posted to the Seller Central forums that the Business Solutions Agreement changes effective 2026-03-04 [A6-S26]. Amazon's own announcement text:

"We'll add requirements for the use of automated software or AI agents to access Amazon Services, and we may restrict their access in certain instances." [A6-S26]

"We'll add BSA restrictions on using Amazon materials or services for AI development with enhanced protection against reverse engineering." [A6-S26]

Three baseline obligations on agents, per the same announcement [A6-S26]: they must "clearly identify themselves as automated systems", "comply with the new Agent Policy at all times", and "cease access if Amazon requests". Acceptance is automatic: "Your continued use of Selling Services after the effective date constitutes acceptance of these changes." [A6-S26]

This is the single most important design constraint in this Finding. A product built on this thesis is, by Amazon's definition, an Agent. It must say so, in the product, at all times.

Parked — I could not obtain the verbatim Agent Policy or BSA Section 19. The BSA is served by a JavaScript app; its content API (sellercentral.amazon.com/help/hub/mons-api/...) returns {"reason":"sign_in"} at every path I tried. See §4 for the exact probes. What follows in blogs is not verified.

Widely repeated secondary claims that I could not confirm and that should not be carried into the Brief: a 12-month audit-trail requirement, a 180-day log retention requirement, a "human authorisation for price changes over 20% within 24 hours" rule, and a forthcoming certification programme for AI seller agents. These appear in [A6-S29] [A6-S30] and several SEO blogs; the strongest of them, [A6-S29], quotes only the same single Amazon sentence I quote above and presents the rest as its own synthesis. Treat all specific numbers as unverified blog content.

1.5 What Amazon lets you read that it did not before

A genuine and surprising expansion: the Customer Feedback API (v2024-06-01) exposes "insights from customer reviews and returns... the same information as the Product Opportunity Explorer" — most positive and negative review topics per ASIN and per browse node, sortable by mentions and star-rating effect, with month-on-month trends and customer snippets [A6-S15]. Role: Brand Analytics or Selling Partner Insights — neither is restricted [A6-S15] [A6-S3].

Two hard limits: it returns insights, not raw review text at ASIN level, and it is not available on AE or SA — US, UK, FR, IT, DE, ES, JP only, refreshed weekly, English only [A6-S15].

So "read reviews" on amazon.ae in 2026 is still: not by API, and not by crawler [A6-S28]. That gap is real and it is GCC-specific.

1.6 Amazon's terms on automation and scraping — operative sentences

Selling Partner API Acceptable Use Policy [A6-S7] (full text retrieved; these are verbatim):

• 3.3 — "Do not request or share Amazon Portal usernames or passwords from Authorized Users."
• 3.7 — "If Amazon Portal access is required to provide features or services that benefit Authorized Users, ask the Authorized User to grant access through secondary user permissions."
• 3.6 — "Do not ask Authorized Users to share information retrieved from Amazon Portals manually or programmatically to circumvent Amazon policies."
• 4.3 — "Do not use, offer or promote external (non-Amazon) data services that vend information or data retrieved from Amazon's websites."
• 4.4 — "Do not aggregate data across Authorized Users' businesses or customers obtained through the Amazon Services API to provide or sell to any parties, including competing Authorized Users."
• 4.5 — "Do not promote, publish or share insights about Amazon's business."
• 2.4 — "Be explicit about any calculations and the use of models such as artificial intelligence in the service you provide, their accuracy and data freshness."
• 2.10 — "Implement data integrity and validation checks within your Application for any analytical processing (e.g. AI models for insights, automated decision-making) that has material impact on an Authorized User's business."
• 3.5 — access keys unused for 90 days are deleted and must be re-applied for.
• 5.2 — "If you are using the Buyer-Seller Messaging Service, you must also support Amazon-approved templates through integration with the Messaging and Solicitations API."

Four of these bite directly on the product design:

1. 4.4 kills cross-seller benchmarking. "How does my ACoS compare to other GCC sellers in my category" is not buildable on SP-API data. This is a real wall for a pitch that leans on network effects.
2. 3.3 + 3.7 kill credential-based automation. You may never hold a seller's Seller Central password. The sanctioned mechanism is secondary user permissions or OAuth.
3. 2.4 makes AI disclosure a contractual obligation, not a nicety — and it predates and reinforces the Agent Policy's self-identification rule.
4. 4.3 constrains what third-party data you may resell alongside your app.

Note the qualifier in 3.6: it prohibits asking users to hand over portal exports "to circumvent Amazon policies" — it does not, on its face, ban a seller uploading their own report. The 006-era "exports in" workflow is therefore not per se prohibited, but it is the weaker and more fragile path.

amazon.ae / amazon.sa Conditions of Use [A6-S27], verbatim:

"You may not extract and/or re-utilize parts of the content of any Amazon Service without our express written consent. In particular, you may not utilize any data mining, robots, or similar data gathering and extraction tools to extract (whether once or many times) for re-utilization any substantial parts of the content of any Amazon Service, without our express written consent. You may also not create and/or publish your own database that features substantial parts of any Amazon Service (e.g. our prices and product listings) without our express written consent."

Combined with the ~101-agent robots.txt block [A6-S28], scraping amazon.ae is contractually prohibited and technically signposted. Do not build on it.

1.7 Noon — there IS a partner API, and it is good

This reverses the working assumption and meets the Area brief's escalation trigger.

noon operates a documented, production noon API Platform with a public documentation site at https://noon-docs.noonpartners.dev/ (HTTP 200, no login, robots.txt = Allow: /) [A6-S32]. In noon's own words: "noon's API Platform provides a consistent, production-grade interface for working with catalogs, orders, fulfillment, and event notifications", for "Sellers... Service providers and partners... System integrators connecting ERPs, OMSs, or custom back-office systems to noon... Developers" [A6-S33].

The gateway is https://noon-api-gateway.noon.partners. There is a Developer Portal at https://developer.noon.partners with webhook destination management, a live-call debugging session, rate-limit dashboards and support cases [A6-S42]. There is a static sandbox [A6-S32].

Documented API domains [A6-S32]:

The multi-tenant integrator flow is real and documented. noon's words: "If you're an integrator building a platform or service that needs to access noon Partner APIs on behalf of multiple sellers, you can use the OAuth flow to programmatically create service accounts in your integrator project and grant them access to seller projects. This eliminates the need for sellers to manually create and share service account credentials." [A6-S34]

The implementation is standards-grade: OAuth 2.0 authorization-code flow with PKCE (S256 required), state for CSRF, multiple registered callback URLs with exact-match validation, and RFC 9207 issuer identification (iss=https://oauth.noon.partners on the callback) [A6-S34]. That is not a bolted-on afterthought.

noon is explicit that sellers must not hand over credentials: "sellers should never manually share their credentials with you" [A6-S35]. Same posture as Amazon's AUP 3.3.

Marketplace coverage. The Pricing API is documented for "reliable, high-volume price synchronization across AE, SA, and EG" [A6-S36]. Content is bilingual by design — "Submit bilingual content (English and Arabic) and track completeness and QC status independently per language" [A6-S38], which is directly relevant to 006's parked Arabic-listing gap.

The gate. Access is not open registration. Prerequisites [A6-S34]: "You must be registered as a noon Partner Integrator", you need integrator service-account credentials, and "You have requested and obtained OAuth client credentials (client_id and client_secret) from noon — contact noon to request these credentials." Adding a callback URL also requires contacting support [A6-S34]. So: a real programme, with a human gate, and no published eligibility criteria or SLA.

Seller-side self-service credentials do exist without integrator status: a service account created in the Seller Lab access app, downloading a JSON key, 30-day session lifetime, one service account per partner, max 5 keys, optional IP allowlist [A6-S35]. Rate limits are per-project with a fixed-window main limit plus burst protection [A6-S40].

What Noon does not have. In the documented surface (127 doc URLs, 51 API reference pages [A6-S32]) there is no advertising or sponsored-products API, no reviews API, no buyer-messaging API, and no search-term or search-query analytics. Impex export exists but its category list is not enumerated in the docs [A6-S32]. Reporting is therefore the weakest documented area.

2. Operation-level matrix

2.1 Amazon

R = read, W = write. "Role" is the SP-API role or the Ads API. All named roles are unrestricted unless marked.

* FBA Inventory has addInventory/createInventoryItem, but these are sandbox/limited-programme operations, not general stock setting. General stock writes go through row 3 or 4. † Send-only, and only from a fixed list of Amazon-approved templates (confirm order, confirm delivery, legal disclosure, warranty, invoice, etc.) [A6-S13]. AUP 5.2 requires template compliance [A6-S7]. ‡ Region-level NA/EU/FE [A6-S16]; marketplace-level FBA inbound feature parity on amazon.ae/.sa (partnered carrier, AUH1 routing) not verified — see §4.

2.2 Noon

2.3 The shape of the two ceilings

The asymmetry is the finding: Noon matches Amazon on operations and loses badly on intelligence. A "unified" product is credible for listing, pricing, stock and orders; it is not credible for advertising or search analytics, because on Noon those APIs do not exist.

3. Reconciliation notes

Reconciliation note — Ads MCP access. 006:[L09] says the Amazon Ads MCP server is "partner-only" and that "an individual seller reaches it through an agency or an integrated software platform." Amazon's own MCP documentation says the prerequisite is "an existing LwA application and Amazon Developer account with access to the Amazon Ads API" [A6-S24], and the Ads onboarding says "Direct advertisers, partners, and integrators are all eligible to apply" with review "up to 1 business day" [A6-S20]. Resolved in favour of the primary documentation. 006's source was a practitioner podcast; the claim was true of the Partner Network route and wrong as a general statement.

Reconciliation note — Noon. The Area brief and SCOPE both anticipated that Noon might have no partner API, and asked for demonstrated absence. The opposite is true. Reached by two independent paths on 2026-09-05: (a) hostname probing found developer.noon.partners and oauth.noon.partners returning HTTP 200 behind a login.noon.partners redirect; (b) helpcenter.noon.partners/sitemap.xml (488 URLs) contains an article "noon API platform" which links to noon-docs.noonpartners.dev. Both paths land on the same public docs. Escalated.

Reconciliation note — hostname probing method. My first probe reported curl exit 000 for *.noon.com developer hostnames and I nearly recorded that as DNS absence. That was wrong. *.noon.com and *.noon.partners are wildcard DNS; every name resolves, and non-existent services return HTTP 418 from an Envoy catch-all. A bogus control (qqq-bogus-xyz123.noon.partners → 418) establishes the baseline. So for Noon: 418 = does not exist; 200 = exists. Real: login, developer, integration, oauth, catalog, help/helpcenter (.noon.partners); sell.noon.com → sell.withnoon.com. Not real (418): docs, api, apidocs, integrations, auth, seller, sellerlab, ads, dev, sandbox, openapi, swagger. The lesson generalises: a wildcard DNS zone makes naive absence-testing produce false negatives.

Reconciliation note — the Agent Policy's specifics. ppc.land [A6-S29], EcommerceBytes [A6-S30] and a cluster of SEO blogs report identical-sounding but mutually inconsistent obligations (12-month audit trails vs 180-day logs; a 20% price-change human-authorisation threshold; a forthcoming certification programme). Checked against the strongest of them: it quotes exactly one Amazon sentence and presents everything else as synthesis. Amazon's forum announcement [A6-S26] contains none of those numbers. Resolved: only the three baseline obligations and the AI-development restriction are treated as established; every number is parked as unverified.

Reconciliation note — "exports in, recommendations out." Not contradicted so much as re-scoped. 006 was describing what practitioners do; A6 was asked what a third-party developer may do. Both are true at once, and the gap between them is precisely the product opportunity.

4. Open questions / parked

Could not obtain — primary source gated.

• BSA Section 19 and the Agent Policy, verbatim. Probed: sellercentral.amazon.com/gp/help/external/G1791, /help/hub/reference/external/G1791?locale=en-US, sellercentral.amazon.ae/gp/help/external/G1791?language=en_AE — all return a JavaScript shell (HTTP 200, no policy text). The content API behind it (/help/hub/mons-api/{reference/external/G1791, GetHelpContent, HelpContent, reference/G1791, external/G1791}) returns HTTP 403 {"reason":"sign_in"}. Retrieving it needs a logged-in Seller Central session — Ilia has one. This is the single highest-value follow-up in this Area.
• Amazon Ads API License Agreement, at advertising.amazon.com/API/docs/license-agreement — same JS-shell problem; the docs CDN has no markdown for it. Its automation clauses are unread.
• Noon's seller/partner terms of service. Not located before budget exhaustion. No quote available on scraping, robots or automated access. Do not read this as "Noon has no such clause."
• noon.com/robots.txt — my fetch returned no bytes; unresolved. Worth one retry.

Could not determine — not documented.

• Noon Impex export categories. GetExportCategoryList exists but the docs do not enumerate what can be exported, so "can you pull a Noon business report" is genuinely open. This decides whether the Noon side can support analytics at all.
• Noon integrator eligibility: no published criteria, application form, SLA, fees, or approval rate. "Contact noon" is the whole documented process [A6-S34].
• Whether Noon has any advertising API not in the public docs. Noon sells sponsored placements in its seller UI; absence from 51 documented API reference pages is strong but not conclusive.
• FBA inbound feature parity on amazon.ae/.sa. The API is region-supported [A6-S16]; whether Amazon-partnered carrier, box-content workflows and AUH1 routing behave as in the EU is unverified.
• Amazon Search Terms report (GET_BRAND_ANALYTICS_SEARCH_TERMS_REPORT) store availability: the docs give role and brand-representative requirements but no store list [A6-S11]. Unlike SQP, .ae/.sa is not confirmed.
• Ads MCP maturity. A docs TOC node reads "MCP Tools (beta)"; the overview page [A6-S23] carries no beta label. The "open beta launched 2026-02-02" date is blog-sourced [A6-S29]-adjacent and unverified.
• SP-API approval rate for pre-revenue applicants. Requirements are documented; outcomes are not. Nothing published says how often a company with a website and no customers is approved.

Method limitation. This session exhausted its WebSearch budget (200/200) partway through. Everything after that point is WebFetch and direct HTTP probing of known URLs. Where I say "not found", read it as "not found by targeted fetch", not "does not exist" — except where a probe method is stated, as in the Noon 418 baseline above.

Vendor-connector corroboration outstanding. A parallel Scout was tasked with extracting, from the vendors' own docs, what credential Unicommerce / Omniful / ChannelEngine / Anchanto / Webkul / CedCommerce / Zoho / Salla / Zid require for a Noon connector. That evidence would confirm the API is used in the wild, not merely published. Not returned at time of writing.

5. What this does NOT cover

• Amazon DSP, AMC and Amazon Marketing Stream. Reachable through the same Ads credentials but with their own onboarding; not assessed.
• Vendor Central / 1P. Out of scope; this Inquiry's beachhead is a 3P seller.
• Rate limits as a capacity model. Both platforms publish limits [A6-S40]; I did not model whether they support N sellers at a given refresh cadence. That is a build question and belongs in the Brief's sequencing, not here.
• Cost. No SP-API or Ads API fees are documented; Noon publishes none. Whether an operator's unit economics survive Data Kiosk/report polling at scale is unmodelled.
• Namshi. noon's FBPI docs reference Namshi as a second marketplace on the same webhook [A6-S32]. Not investigated; it may be a free adjacency.
• Legal opinion. I have quoted contract language. Whether a given product design breaches it is a lawyer's call, not a Scout's — and the Agent Policy is unread (§4).
• amazon.eg and noon Egypt as commercial targets. Both APIs support EG; the market is outside SCOPE.
• Salla / Zid / Shopify own-store platforms. Out per SCOPE unless they cross into marketplace management.

Source legend

Amazon developer documentation was retrieved as markdown via the documented llms.txt convention (https://developer-docs.amazon/sp-api/llms.txt, which states "Append .md to any documentation page URL to get its markdown version"). Amazon Ads documentation is a client-rendered app; its source markdown was retrieved from the documented content CDN https://d3a0d0y2hgofx6.cloudfront.net/en-us/<path>.md, indexed via en-us/toc2.json. All accessed 2026-09-05.