• Overview — what the portal offers and how to get access
• Support Cases — raising a case, tracking it, replying in thread
• Rate Limit — your rate limit analytics and per-endpoint configuration
• Debugging Session — capturing live requests and responses, including headers and bodies, for one service and one API user over a bounded window
• Event Notifications — Overview, Destinations, Analytics, and Logs

Debugging sessions are worth a look​

If you've never used one: a debugging session captures full request and response payloads — headers and bodies, per call — scoped to a single service and API user for a bounded window. It's the fastest way to see exactly what we received from you and exactly what we sent back. The page walks through setting one up.

The portal itself is at developer.noon.partners.

Guided walkthrough​

First-time users are walked through where each part of the portal lives — rate limit analytics, event notification destinations, debugging sessions, support cases. It's skippable, and you can re-trigger it later from settings, which makes it a quick way to bring a new colleague up to speed.

Dark mode​

The portal follows your operating system's light or dark preference automatically. There's a manual toggle if you'd rather pin one, and that choice persists.

Both are interface changes only — no API behaviour changed, and nothing you've built against the portal needs updating.

Cases live under Support in the Developer Portal. From there you can open a new case, see everything you've raised, and open any one of them to read and continue the conversation. There's a full walkthrough in Support Cases.

Case lifecycle​

A case moves through four states:

A case with no activity for 15 days closes automatically. If that happens and the problem hasn't gone away, open a new one and reference the old case.

What to include​

The more of this you provide up front, the fewer round trips:

• The endpoint and HTTP method you called
• A request ID or timestamp, so we can find it in the logs
• What you expected versus what came back
• Whether it reproduces or happened once

If failures are broad rather than specific to one call, the API health status page may already show the cause.

Each page carries actions to copy its Markdown source or download it as a .md file. Endpoint pages also have a copy button on the method and path, so grabbing just the route doesn't mean selecting text by hand.

Markdown round-trips cleanly where a screenshot or a copy-paste from rendered HTML doesn't: tables stay tables, code blocks stay code blocks, and enum values survive intact.

The site also publishes an llms.txt index, so tooling that understands that convention can discover the full documentation set on its own.

Each service group rolls up to a single state:

A group shows as Outage if any endpoint under it is in outage, and Degraded if any endpoint is degraded.

How it's calculated​

The page reads observed error rates directly — it isn't updated by hand, so it stays accurate during an incident without anyone remembering to flip a switch.

What it shows, and what it doesn't​

It reflects current state only; there's no historical availability chart today. Establishing what happened during a window that has already passed still needs a conversation with us.

The page is public and needs no login, so it's safe to link from your own runbooks and dashboards.

This is the first endpoint on the Returns service — a single RPC, scoped to the merchants your credentials cover.

Why you'd use it​

A returned parcel arrives at your facility carrying a barcode. Scan it, call ListReturnReferences, and you get the return items associated with it across all your partner merchants in one response — enough to route the parcel without a manual reconciliation step.

The endpoint and its full schema are in the Returns section of the API reference.

The Querying logs guide covers the query editor in the Developer Portal: how to filter delivery attempts, what each field in a log record means, and how to read the results when a delivery failed.

What this is good for​

• Confirming whether an event was dispatched at all, versus dispatched and rejected by your endpoint
• Seeing the exact payload we sent, when your handler logged something unexpected
• Pinning a gap down to a specific time window

The guide is linked under Event Notifications in the docs sidebar, next to the event type references.

Guides​

Five documents walk through a first integration end to end:

• Content API overview — how the service fits into the catalog lifecycle
• Quickstart — your first successful call
• Discover category attributes — find out what a category requires before you submit
• Submit a product — build and send a valid product payload
• Track and fix — read back content status and correct rejections
• Go live — the checklist before you move to production

The published reference is the source of truth for these endpoints: field and enum names match the service exactly, and rate limits render from the live specification.

SKU deletion​

Both accept batches. Because parent deletion cascades, check what sits underneath a parent before you call it.

Bulk barcode import​

The usual flow is to call GenerateImportSignedUrl, upload your file to the URL it returns, pass that file_url to CreateBarcodeImport, then poll GetImportStatus with the returned reference until it completes. If your data already lives in BigQuery you can skip the upload and pass bq_table instead.

Full request and response shapes are in the Catalog section of the API reference.