What the orosy Buyer API is — many Japanese suppliers, one API

A wholesale sourcing API that lets you search roughly 200,000 products from multiple Japanese suppliers through one API and order them from a single cart. Because you buy after you sell, you can grow your assortment without holding inventory. From search to ordering, payment (3-D Secure supported), and getting qualified invoices, everything sourcing needs is done through this API.

New here? Start with Talk to your AI and source from Japan — no code, about 15 minutes.

Authentication

Method	Header	Used for
API key	`Authorization: Bearer orosy_...`	Almost everything — product search, cart, orders
Cognito ID token	`Authorization: Bearer <id_token>`	`/v1/me/*` only (key management, payment methods, invoices)

You issue API keys yourself from the portal once your account is approved — no OAuth implementation needed. Sign up on the buyer portal; the UI is in Japanese, and the English guide walks you through it.
Orders placed with an orosy_demo_... (test) key are for testing only — no real charge, no real inventory movement. Use POST /v1/orders/{order_id}/simulate to freely replay the state transitions from confirmed reservation through cancellation.

A typical flow

GET /v1/products — cross-supplier search (keyword / product code / JAN / price band / stock)
PUT /v1/cart/items — add to one cart across suppliers
POST /v1/orders — order with a shipping address (if the price moved, 409 PRICE_CHANGED protects you)
GET /v1/orders/{order_id} — track the confirmed-reservation and shipping state
GET /v1/me/orders/{order_id}/invoice — get the qualified-invoice PDF

Design promises

Price-change guard: if the wholesale price changed after the item went into the cart, the order is not auto-confirmed and returns 409. It confirms at the new price only when you explicitly accept with accept_price_change: true.
Reservation-based billing: billing happens only against what is reserved (that is, what actually arrives). If everything is out of stock, no billing occurs.
Idempotency: to prevent duplicate orders and duplicate authorizations on retry, we recommend sending an Idempotency-Key header with POST /v1/orders. A resend with the same key returns the original order (it does not create a new one). Even without the header, a same-cart double submit is deduplicated server-side.

Guides

Your first order in 15 minutes — search, cart, test order, confirmed reservation
Talk to your AI and source from Japan — search to test order without writing code (about 15 minutes)
Order from an AI agent (MCP) — setup steps and the tool list
Partial out-of-stock and billing — you are billed only for what is reserved
Sign-up walkthrough (English, annotated screens)

Reference

The full endpoint specification lives in the API reference.