Track orders and the devices they ship

Every sale you make — through the API or in the partner portal — becomes an order you can read, and the hardware it ships ends up in your device list. Here's how to follow both from your own systems.

You'll need a key with orders:read for orders and devices:read for devices. Your account needs the Order module for the first and the Devices module for the second.

List your orders

GET/v1/orders returns your organization's orders, newest first. Line items are left out to keep the list small.

curl "https://cloud.mergewifi.com/v1/orders?limit=25" \
  -H "Authorization: Bearer $MERGEWIFI_API_KEY"

{
  "object": "list",
  "data": [
    {
      "object": "order",
      "id": "8f14e45f-ceea-4a0b-9c1f-2d3b4a5c6d7e",
      "order_mode": "pos",
      "status": "processing",
      "payment_status": "submitted",
      "total": 412.87,
      "created_at": "2026-07-30T17:12:04.000Z"
    }
  ],
  "has_more": true,
  "next_cursor": "eyJpZCI6IjhmMTRlNDVmIiwidHMiOjE3ODU0MzIwMDAwMDB9"
}

Narrow the list with status or order_type. Both are exact matches, and a value with no matches returns an empty list rather than an error. Sales made at checkout carry order_mode: "pos".

Page through them

Orders come a page at a time. Pass limit (1 to 100, default 25). While has_more is true, ask for the next page by sending the response's next_cursor back as starting_after:

curl "https://cloud.mergewifi.com/v1/orders?limit=100&starting_after=eyJpZCI6IjhmMTRlNDVmIiwidHMiOjE3ODU0MzIwMDAwMDB9" \
  -H "Authorization: Bearer $MERGEWIFI_API_KEY"

Cursors stay correct when new orders arrive while you're paging, so you never skip one. A limit outside 1–100 is rejected rather than quietly trimmed. More in Pagination.

Read one order

GET/v1/orders/{id} returns a single order with its line_items. A checkout session's id works here too — it's the same record.

curl https://cloud.mergewifi.com/v1/orders/8f14e45f-ceea-4a0b-9c1f-2d3b4a5c6d7e \
  -H "Authorization: Bearer $MERGEWIFI_API_KEY"

{
  "object": "order",
  "id": "8f14e45f-ceea-4a0b-9c1f-2d3b4a5c6d7e",
  "status": "processing",
  "payment_status": "submitted",
  "billing_reference": "…",
  "submitted_at": "2026-07-30T17:12:04.000Z",
  "completed_at": null,
  "line_items": [
    { "kind": "device", "sku": "M-11", "name": "MergeWiFi Mini", "quantity": 1, "unit_price": 199.99 },
    { "kind": "plan", "sku": null, "name": "Unlimited 5G", "quantity": 1, "unit_price": 49.99 }
  ]
}

What to read:

• status follows fulfillment. You'll see values like pending, processing, shipped, completed, delivered and cancelled. Treat it as a label rather than a fixed list. completed_at is set once the order is completed or delivered.
• payment_status is where a card-paid sale sits in payment — the same states a checkout session goes through, like awaiting_payment and submitted. It's null for invoiced orders.
• billing_reference is our fulfillment reference. Quote it if you contact us about an order.
• line_items are tagged by kind: device, plan and addon on checkout sales.
• tax_basis says how tax was worked out: destination is calculated for the shipping address.

An order that isn't yours returns 404, exactly as if it didn't exist.

Find the devices an order shipped

How a device shows up depends on where it came from:

• Equipment your customer already had. The device line on the order carries its serial (or iccid for a SIM). The device is moved onto your account when the sale is paid.
• Hardware shipped from our warehouse. Nobody knows the serial until fulfillment packs a unit, so it isn't on the order's line items. Once the unit ships, a daily pass adds it to your device list.

Either way, a device appears in the device calls after our next inventory refresh, which runs every 15 minutes. Look it up by serial — the one on the order line, or from the box — with an exact match:

curl "https://cloud.mergewifi.com/v1/devices?serial=M11-2416002345" \
  -H "Authorization: Bearer $MERGEWIFI_API_KEY"

Browse your devices

GET/v1/devices returns the devices on your account, newest first, paged exactly like orders: limit, then next_cursor as starting_after while has_more is true.

Filter with activated and reachable (true or false), serial, model, data_plan (a plan name, or unassigned), or free text across serial, label and id with q.

curl "https://cloud.mergewifi.com/v1/devices?activated=true&reachable=false" \
  -H "Authorization: Bearer $MERGEWIFI_API_KEY"

GET/v1/devices/{uuid} returns one device by its id:

curl https://cloud.mergewifi.com/v1/devices/0d5102c1-b8d2-4ba4-b6aa-43ed91d768c0 \
  -H "Authorization: Bearer $MERGEWIFI_API_KEY"

{
  "object": "device",
  "id": "0d5102c1-b8d2-4ba4-b6aa-43ed91d768c0",
  "serial": "M11-2416002345",
  "label": "Warehouse dock 3",
  "activated": true,
  "reachable": true,
  "model": "M-11",
  "data_plan": { "id": null, "name": "IoT 5GB Monthly" },
  "network_group": { "id": null, "name": "Nationwide" },
  "data_used_bytes": 2411724800
}

• id is what every other device call takes.
• activated and reachable are separate on purpose: a device can be in service and switched off, or online and not yet in service.
• data_used_bytes is always bytes.
• data_plan and network_group give the names. To change either, take an id from the lists in Start service.

Keep your records in sync

• Order statuses are refreshed from fulfillment every 30 minutes, and device details every 15 minutes, so there's little point polling for those changes more often.
• To catch new orders, page from the newest and stop when you reach an id you've already stored.
• Use filters to keep requests small — ?reachable=false is a quick list of devices that need a look.
• Every response counts toward your rate limit. See Going live before you schedule a sync.

Related: Run your own checkout · Manage a device · Diagnose a device · Going live