What Customer Data Coupang's Open API Actually Gives You

The short answer is that Coupang's Open API gives you everything you need to run a store — and almost nothing you need to build a customer marketing list. You can pull products, orders, inventory, shipping and return centers, exchange and cancellation requests, customer inquiries, and settlement. But buyer email comes back as an empty string, and the customer's real mobile number is increasingly replaced with a proxy relay number rather than a raw phone number.

If you are used to Shopify or Amazon, that boundary matters before you write a line of integration code. A CRM, a win-back email flow, or a cross-channel customer-reconciliation project built on API-sourced contact data will never receive the data it depends on. So it is worth mapping exactly where the wall sits — and why it is a permanent design choice, not a gap Coupang plans to close.

What the Open API is actually for

Coupang's Open API exposes operational objects. Think of it as the control surface for a store, not a window into the shopper.

The endpoints let you manage the things a store operator touches every day:

• Products and listings — create and update catalog items and their attributes
• Purchase orders (orders) — pull the orders that need fulfilling
• Inventory — sync stock levels
• Shipping and return centers — the logistics addresses tied to your account
• Exchange and cancellation requests — the flows for returns, swaps, and cancellations
• Customer inquiries — the questions buyers submit against your listings
• Settlement — the money side, so you can reconcile payouts

That is enough to run a store programmatically. It is not enough to own the end customer. The distinction is deliberate: the marketplace is designed so that you operate the storefront while Coupang remains the steward of the shopper's identity.

The hard privacy boundary: email comes back empty

Buyer email is the cleanest example of the boundary, because it does not arrive partially masked — it does not arrive at all.

Per Coupang's stated security and privacy policy, the buyer email field is returned as an empty string in the order-list response, the single-order response, and in the responses for Coupang customer inquiries. It is not truncated, not tokenized, not available on a delayed schedule. It is simply blank.

This is the single most common assumption Western sellers carry into a Coupang integration, and it is the one that quietly breaks a retention plan months later. If your entire post-purchase marketing motion assumes you can export an email list, the plan is built on a field that will always be empty. You can verify the exact field behavior against Coupang's own developer documentation before you commit engineering time — that is the authoritative source for which fields populate and which do not.

'Safety numbers' instead of real phone numbers

Where you do need to reach a customer — to coordinate a return pickup or an exchange — Coupang increasingly hands you a proxy relay number rather than the shopper's actual mobile.

These proxy numbers are commonly called safety numbers (안심번호). A safety number routes a call or message to the real customer without ever exposing their raw phone number to you. It lets you complete the logistics — arrange the courier, confirm the swap — while Coupang holds the underlying personally identifiable information.

Two practical properties are worth designing around:

• The relay number is not the customer's identity. It is a routing handle tied to a specific transaction stage. Treat it as an operational token, not a contact you can store and re-market to later.
• It may need re-fetching. A safety number surfaced at one stage of a return or exchange flow may differ from — or expire relative to — the one you need at a later stage, so your integration should re-query rather than cache a number indefinitely.

This is the same logic as the email rule, applied to a field you genuinely need for operations: Coupang gives you just enough to complete the task, and nothing that would let you build a standing contact record.

Why this happens — and why it will not reverse

None of this is a temporary API limitation. It is a regulatory design choice, and it points toward more masking over time, not less.

Under Korea's personal-information framework — the Personal Information Protection Act (개인정보 보호법, PIPA) — buyer contact data is protected personal information, and the marketplace is treated as the primary data steward for the transactions that happen on it. The seller is a downstream party. Coupang's masking is how the platform discharges its own obligations under that regime rather than passing raw PII to thousands of third-party sellers. You can read the statute itself on the government's law portal at law.go.kr if you want the primary text.

The correct read for a decision-maker: plan as if the customer's identifying data will never be yours to hold, because under this framework it is designed not to be.

What 'automating Coupang' actually means

So automation on Coupang is real and high-value — it just lives on the operations side of the wall, not the marketing side.

Here is the realistic split of what an integration can and cannot do:

• You can automate: listing creation and updates, order fulfillment, inventory sync, return and exchange coordination, and settlement reconciliation. These are the repetitive, error-prone tasks where an API earns its keep.
• You cannot automate: direct-to-consumer marketing off an exported contact list. There is no email to export and no raw phone number to dial.

Direct-to-consumer marketing on Coupang has to run through Coupang's own on-platform tools — ads, promotions, and the messaging surfaces the platform controls — rather than through contact lists you extract and load into an outside system. That reframes the goal of a Coupang integration: you are automating the store, and you are reaching customers inside the platform's walled tooling. If you want to see what on-platform performance tooling looks like in practice, the way Sales Radar turns daily performance data into weekly action is a concrete example of working with — rather than around — the data Coupang exposes.

Build-vs-buy: the integration is not a one-time project

If you do build in-house, budget for maintenance, not a single sprint. The API surface moves on Coupang's schedule.

Fields, schemas, and endpoints change over time. Attribute rules have been tightened category by category. New Rocket Growth product schemas have rolled out gradually rather than all at once. An integration that works today can break — or silently start returning different data — when a category's rules change or a schema version is superseded. That is ongoing engineering, not a one-time build.

The most durable design principle follows directly from the privacy boundary: key your data flow on stable operational identifiers, not on customer-identifying fields. Order identifiers, shipment identifiers, and relay (safety) numbers are the handles the API will reliably give you. Buyer email and raw phone numbers are the handles it will not. If your internal records, your logic, and your joins are built on the operational identifiers, your integration survives both schema churn and the direction of the privacy regime. If they depend on customer PII, they were fragile from the start.

This also shapes how you handle the parts of the flow that touch a real customer indirectly. When Coupang runs the customer-facing return under Rocket Growth but the returned unit re-enters your inventory, or when the inbound verification desk reviews labels and certification evidence, you are working with operational objects and transaction stages — exactly the identifiers the API is built to hand you — not with the shopper's contact details.

Common questions

Can I get buyer email addresses from Coupang's Open API? No. The buyer email field is returned as an empty string in the order-list, single-order, and customer-inquiry responses per Coupang's stated privacy policy. There is no API path to a usable email address.

What is a safety number (안심번호)? It is a proxy relay number that routes calls and messages to a customer without exposing their real mobile number. It lets you complete return and exchange logistics while Coupang holds the underlying personal data. It may need re-fetching at later stages of a flow rather than being cached.

Is the masking likely to loosen over time? No. It follows from Korea's Personal Information Protection Act (PIPA), under which the marketplace is the primary data steward. The direction is toward more masking, not less, so plan accordingly.

Then what should a Coupang integration actually automate? Listing creation, order fulfillment, inventory sync, return and exchange coordination, and settlement reconciliation. Direct-to-consumer marketing has to run through Coupang's own on-platform ad and promotion tools, not through exported contact lists.

Where can I verify the field behavior myself? Check Coupang's official developer documentation for the exact field-level behavior, and read the PIPA statute on the government portal at law.go.kr for the regulatory basis.