A server-to-server API so you can resell mouroam's catalog — SMM engagement, ready-made social/email accounts, VPN access, travel phone-number eSIMs, and mobile proxies — on your own storefront, without your customers ever seeing which upstream provider sits behind it.
\nThis documentation is public and free to read. Every endpoint, field, and example below was pulled directly from the live implementation, not written from memory — you do not need an account to browse it. You DO need your own live API key to actually call anything (see \"Getting a key\" below); every request in this collection inherits Bearer auth from a blank api_key collection variable, so nothing here can leak or spend a real key.
/dashboard/account (a pre-filter, not the real gate)./dashboard/account, submit a \"Request API access\" application — an optional note about your use case helps the review.sk_live_...) and cannot be shown again. There is currently no self-service rotation; contact support if you lose it or need it revoked and reissued.api_key variable in this collection (Variables tab, top right) to that value and you're live.GET /catalog?kind=... → browse what you can resell\nPOST /quotes → lock in a real, server-computed price (valid 10 minutes)\nPOST /orders → place the order against that quote\nGET /orders/{id} → poll for status, or configure a webhook (see below)\nGET /orders/{id}/delivery → fetch credentials/activation info once ready\nNothing you send is ever trusted as a price. The server recomputes it at both quote time and order time, and refuses to charge more than the quote you approved — if the live price moved in between, the order lands failed with error_code: \"price_changed\" instead of silently overcharging you. Get a fresh quote and retry with a new external_order_id.
Two endpoints round out the API without being part of this core flow: GET /balance (your account's current spendable balance) and, for a fulfilled smm order, GET/POST /orders/{id}/refill (see \"Refills\" below). /smm/orders and /smm/orders/{id} are also available as plain aliases for /orders and /orders/{id}, if you prefer a kind-scoped path — identical behavior, no separate rate limit.
Authorization: Bearer sk_live_your_own_key_here\nContent-Type: application/json (POST only)\nA key resolves to exactly one mouroam account and spends that account's wallet balance through the same debit path the mouroam dashboard itself uses — it grants no other access. An unknown key and a revoked key are indistinguishable: both return 401 unauthorized, so a caller can never probe which part of a credential was wrong. A revoked key does not affect your account's underlying access approval — contact support for a replacement key rather than reapplying.
There is no order (disposable OTP numbers) or rental kind — both are permanently disabled and won't be added without a separate explicit decision.
esim_topup has one extra catalog requirement: pass &esim_id=<your already-purchased eSIM's id> on GET /catalog — that eSIM must already be active (fully provisioned) before it has any top-up options.
A smm catalog product (and a placed smm order) also carries refill_mode (\"api\"/\"manual\"/\"none\") and, when applicable, refill_window_days — see \"Refills\" below.
Every response is one of:
\n{ \"success\": true, \"data\": { ... } }\n{ \"success\": false, \"error\": \"human-readable message\", \"code\": \"machine_readable_code\" }\nX-Request-Id is set on every response — include it when reporting an issue. A 429 always sets Retry-After: 300.
POST /orders, POST /orders/{id}/refill): 30 per 5 minutes.GET /orders/{id}/refill): 120 per 5 minutes.external_order_id (yours, 1–128 characters) is what makes retrying safe: resubmitting the exact same external_order_id always returns the exact same order — it is never placed twice. If that id was already used with a quote_id resolving to different order parameters, the request is refused as 409 idempotency_conflict rather than silently substituted. On a genuinely unknown outcome (503 temporarily_unavailable, a network error on your end) always retry with the same external_order_id — never mint a new one just because a call failed; a new id there risks a real double order.
queued, processing, pending, purchasing, in_progress, partial, active, completed, delivered, canceled, refunded, failed, review_required.
review_required means the order needs a human on our side before it can move — but it covers two genuinely different situations, so always branch on the order's error_code, never on the status alone:
error_code: \"confirmation_pending\" — the last purchase attempt got an unclear response from the upstream supplier (a timeout, a 5xx). We genuinely don't know whether it went through, so it's never auto-refunded and never silently retried on top of a possibly-real charge. This one does not resolve on its own on any fixed schedule — it requires a human to confirm the real outcome. If it sits for more than a few hours, contact support with the order id rather than waiting indefinitely.error_code: \"delivery_overdue\" or \"delivery_stalled\" (smm only) — the purchase itself was confirmed fine; it's delivery that is late, or has stopped advancing. These carry a 24-hour internal review target. delivery_stalled can clear by itself if the supplier resumes delivering, in which case the order simply returns to its normal status (in_progress etc.) with no action from you — treat it as \"watch\", not \"escalate immediately\".An integration that checks error_code === \"confirmation_pending\" to detect the review state will silently miss the two delivery reasons. Match on the review_required status, then read error_code for the reason.
refunded_usd_cents / net_price_usd_cents are always present on an order and reflect any partial or full refund recorded so far — trust these over status alone for your own accounting (an SMM order that under-delivers can be partially refunded while still showing in_progress).
A freshly placed order (POST /orders returning 202) starts with almost nothing filled in — just id, external_order_id, kind, product_id, status: \"queued\", version: 0, and timestamps. quantity/price_usd_cents/etc. only appear once the first status snapshot lands, moments later — poll GET /orders/{id} or wait for the webhook rather than assuming those fields exist on the immediate response.
A routed smm order (followers/likes/views/subscribers) that drops after delivery can request a refill through GET/POST /orders/{id}/refill (see the \"Refills\" folder). Whether a refill is possible at all, and how it gets fulfilled, is driven entirely by that product's refill_mode — already visible on the catalog entry before you ever order, and on the order itself afterward:
\"none\" — this supplier tier carries no refill guarantee. The endpoint always returns 409 refill_unavailable.\"api\" — the supplier's own refill endpoint is called directly the moment you POST. status reflects its real, polled outcome: submitting → pending → completed/rejected.\"manual\" — this supplier only offers a refill guarantee outside any automatable API. A POST queues a manual_review request for a human on our side to verify against the real supplier record and honor it — not auto-resolved, but not ignored either.refill_window_days is how many days after the order's completed_at a refill can still be requested at all. At most one active refill request per order at a time, and at most one submission every 24 hours per order — hitting either limit returns 409 refill_unavailable, same as requesting one outside the window or on an order that never actually fulfilled with a supplier.
Separately, an order itself can carry its own error_code once it lands failed or review_required — a field on the order object, not an HTTP status:
There is currently no self-service API to register your own webhook — contact mouroam with your endpoint URL and an admin wires it up against your account (per account, not per key, so rotating a key never silently breaks delivery).
\nOn any change to an order's public snapshot, mouroam POSTs to your URL:
POST <your webhook_url>\nContent-Type: application/json\nX-Webhook-Id: <event id>\nX-Webhook-Timestamp: <unix seconds>\nX-Webhook-Signature: v1=<hex hmac>\nX-Webhook-Event: order.updated\n{\n \"id\": \"event-uuid\",\n \"event\": \"order.updated\",\n \"created_at\": \"2026-09-16T15:12:03.000Z\",\n \"version\": 3,\n \"data\": {\n \"status\": \"completed\",\n \"currency\": \"USD\",\n \"quantity\": 500,\n \"price_usd_cents\": 2495,\n \"refunded_usd_cents\": 0,\n \"net_price_usd_cents\": 2495,\n \"id\": \"order-uuid\",\n \"external_order_id\": \"your-own-order-id\"\n }\n}\nImportant: data is the raw internal status snapshot plus id/external_order_id merged in — it is not byte-identical to GET /orders/{id}. It does not include kind, product_id, created_at, or updated_at (those are added only by the GET /orders/{id} response). It also never includes refill state — refills are tracked separately via GET /orders/{id}/refill and do not trigger an order.updated webhook of their own. If your handler needs those, call GET /orders/{id} on receipt rather than assuming the webhook body has everything.
Verify the signature yourself before trusting a callback:
\nexpected = HMAC_SHA256(your_webhook_secret, \"<X-Webhook-Timestamp>.\" + <raw request body bytes>)\nvalid = hex(expected) === the part of X-Webhook-Signature after \"v1=\"\nYour endpoint must be a public HTTPS URL on port 443, no embedded credentials, no fragment, and DNS resolving only to public (non-private, non-loopback, non-link-local) addresses — anything else is rejected at configuration time. Delivery retries on failure with exponential backoff starting at 1 minute and doubling each attempt, capped at 24 hours between attempts, for several days; a 2xx response stops retries. Make your handler idempotent on (order id, version) — a retried delivery and your own poll can both land. If your endpoint is down for an extended stretch, GET /orders/{id} still works — this API never depends on a webhook actually arriving.
Questions, a webhook URL to register, or a lost/exposed key that needs revoking and reissuing: contact mouroam support through the usual channel linked from your dashboard. Include the X-Request-Id from any failing response you're asking about.
Returns the sellable product kinds and the currency every price is denominated in. Cheap to call — not paginated, no query params.
\n{ \\\"product_kinds\\\": [\\\"smm\\\", \\\"social_account\\\", \\\"email_account\\\", \\\"vpn\\\", \\\"esim\\\", \\\"esim_topup\\\"], \\\"currency\\\": \\\"USD\\\" }\nReturns up to 100 products per page for the given kind. platform (smm/social_account/email_account only) and offset are optional; esim_id is required when kind=esim_topup.
{\n \"products\": [ { \"id\": \"uuid\", \"kind\": \"...\", \"currency\": \"USD\", ... } ],\n \"total\": 42,\n \"next_offset\": 100\n}\nnext_offset is null on the last page, never omitted — check for null, not falsy/undefined. Every id is a stable reseller_products.id; pass it straight into POST /quotes as product_id. The fields inside each product object are different for every kind — see the eight example responses on this request (switch between them in the Examples dropdown) for the exact real shape of each, including a routed smm type's refill_mode/refill_window_days/price_quantity fields. from_price_usd_cents/unit_price_usd_cents are indicative only for pricing display; always call POST /quotes for the real, chargeable price before showing a final price to your own customer.
Browse what you can resell. Read-only, no side effects — counts against the 120/5min read rate limit. Field shapes genuinely differ per kind (see each request's own description and examples below) — there is no single universal product shape across the catalog.
Quotes a real price for one product + quantity (+ link, for smm). link is required for smm — any public http/https URL; known tracking params (Instagram stkn/igsh, TikTok _t/_r, YouTube si, X s/t, Facebook fbclid/mibextid, etc.) are stripped server-side automatically. comments (an array of 1–1000 strings) replaces quantity for a Custom-Comments SMM product — the quote's quantity becomes comments.length; sending both or neither where one is required/forbidden gets you invalid_comments. Every other kind ignores link/comments and takes quantity: 1, except smm/social_account/email_account, which take a real quantity.
{\n \\\"id\\\": \\\"quote-uuid\\\",\n \\\"product_id\\\": \\\"uuid\\\",\n \\\"quantity\\\": 500,\n \\\"price_usd_cents\\\": 2495,\n \\\"currency\\\": \\\"USD\\\",\n \\\"expires_at\\\": \\\"2026-09-16T15:10:00.000Z\\\"\n}\nThis price is exactly what POST /orders will charge — pass this quote's id straight in as quote_id. See the Examples dropdown for the common error cases (expired product, out-of-range quantity, temporarily unavailable).
Lock in a real, server-computed price before placing an order. A quote is valid for 10 minutes and is scoped to exactly one product/quantity/link combination — a quote never gets cheaper or more expensive after it's issued, only expired.
\n","_postman_id":"0acb740a-2e30-4c05-889e-7886a8603dd4","auth":{"type":"bearer","bearer":{"basicConfig":[{"key":"token","value":""}]},"isInherited":true,"source":{"_postman_id":"c2d77dde-b214-4f18-8f97-a3ad93190472","id":"c2d77dde-b214-4f18-8f97-a3ad93190472","name":"mouroam Reseller API","type":"collection"}}},{"name":"Orders","item":[{"name":"Place an order","id":"c2a024a1-622b-48bc-9d3a-e541e22cac36","request":{"method":"POST","header":[{"key":"Content-Type","value":"application/json"}],"body":{"mode":"raw","raw":"{\n \"external_order_id\": \"your-own-order-id\",\n \"quote_id\": \"quote-uuid\"\n}","options":{"raw":{"language":"json"}}},"url":"https://mouroam.com/api/v1/orders","description":"Turns a quote into a real, billable order. external_order_id (yours, 1–128 characters) is what makes a retry safe: resubmitting the exact same external_order_id always returns the same order, never places a second one. A quote_id whose request no longer matches what you originally submitted (i.e. reusing an external_order_id with a different quote) is rejected as 409 idempotency_conflict.
Returns 202 Accepted with a near-empty snapshot while the order is still being placed against the upstream supplier (poll GET /orders/{id} or wait for a webhook from there), or 200 OK with the full current snapshot if it settled immediately or you're replaying an external_order_id that already resolved. See the Examples dropdown for both success shapes plus the three error cases you'll hit most: a stale quote_id (quote_expired), an external_order_id reused with different parameters (idempotency_conflict), and a revoked/unknown key (unauthorized).
Lists your orders newest-first, 50 per page. before is a cursor: pass the id (mouroam's internal order UUID, not your external_order_id) of the last order from the previous page to get the next 50.
{\n \\\"orders\\\": [ { \\\"id\\\": \\\"...\\\", \\\"external_order_id\\\": \\\"...\\\", \\\"kind\\\": \\\"smm\\\", \\\"status\\\": \\\"in_progress\\\", ... } ],\n \\\"next_cursor\\\": \\\"6fd6d02b-0000-0000-0000-000000000001\\\"\n}\nnext_cursor is null on the last page.
Fetches one order by mouroam's own id (a UUID). To look it up by your external_order_id instead, see the next request in this folder (same route, ?by=external_order_id).
Never includes a provider order id, provider cost, or delivered secret — those live only in GET /orders/{id}/delivery, and only once ready. refunded_usd_cents/net_price_usd_cents are always present; trust them over status alone. See the Examples dropdown for six real shapes: an SMM order mid-delivery, a completed VPN order, an active/fulfilled eSIM (voice + SMS + data fields), a delivered mobile proxy (expires_at/duration_days), an order stuck in review_required, and one that failed with error_code: \"insufficient_balance\".
Identical response shape to \"Get an order\" — the only difference is the :id path segment is your own external_order_id instead of mouroam's UUID, selected by ?by=external_order_id. Useful when your own system only tracks its own order id and you don't want to also persist mouroam's.
Returns 409 delivery_pending until the order is actually ready — always check order status first, or wait for a webhook, rather than polling this in a tight loop. ?include_raw=true additionally includes raw_record (the exact, complete credential string exactly as delivered by the supplier) for social_account/email_account — a cookie-kind field is never included in fields either way, regardless of include_raw.
Response shape differs by kind — see the Examples dropdown for real shapes for vpn, esim, mobile_proxy (a single opaque credential string, deliberately not parsed into fields), social_account, and email_account, plus the two error cases: not ready yet (delivery_pending), and calling this on a kind with nothing to deliver, like smm (no_credentials — use order status instead, the useful fields like link/start_count/remains are already there).
Place and track orders. Placing an order (POST /orders) costs budget from the tighter 30/5min bucket; everything else here is a read (120/5min). GET /orders/{id} reflects the last known status reconciled from mouroam's own systems — it does not force a fresh check against every upstream supplier on every call, so a webhook or a few seconds' wait is normal between a real-world status change and seeing it here.
Returns the current wallet balance of the mouroam account behind your key — the exact same balance that gets debited when an order is placed. Poll this before placing a large order, or after seeing an order land failed with error_code: \\\"insufficient_balance\\\", to confirm a top-up has landed.
{ \\\"balance_usd_cents\\\": 184523, \\\"currency\\\": \\\"USD\\\" }\nReturns the most recent refill request ever made for this order, or null if none has been requested yet.
{ \"id\": \"refill-uuid\", \"status\": \"pending\", \"mode\": \"api\", \"created_at\": \"...\", \"updated_at\": \"...\" }\nOnly meaningful for a fulfilled smm order — any other kind, or an smm order that never actually placed with a supplier, returns 409 refill_unavailable. status moves submitting → pending/manual_review → completed/rejected. See \"Request a refill\" (POST, same URL) in this folder to actually submit one.
Claims and submits a new refill request for this order. No request body. At most one active request per order at a time, and at most one every 24 hours per order — either limit hit returns 409 refill_unavailable.
mode: \"api\" means the supplier's own refill endpoint was called directly and status reflects its real, polled outcome (pending → completed/rejected). mode: \"manual\" means this order's supplier only offers a manual refill guarantee (see the catalog's refill_mode field, or refill_mode on GET /orders/{id} once you've placed the order) — the request goes to manual_review for a human on our side to verify and honor against the real supplier record, not auto-resolved.
Only works on a fulfilled smm order, outside neither its refill_window_days nor the 24-hour resubmission cooldown — anything else is 409 refill_unavailable. See the two saved examples for a successful api-mode submission and the manual_review case.