Reseller API: act as your customers

The named customer's profile: your id for them, your display name (label), the email you attached, the credit they can still spend (in cents, at your prices), and when they were created and last seen. Requires the X-Reseller-Customer-Id header.

Set the customer's email and your display name for them, ideally right after your own signup flow, so your customer book, your business dashboard and our support all see a person instead of an opaque id. Each field: omitted = unchanged, empty string = cleared, value = set. We never send mail to this address; it is identity, not a channel.

Move store credit on the named customer, from your own backend: grant when they paid you, revoke for a refund on your side or a correction. Amounts are whole cents at your retail prices; one movement is at most $5,000. Send your own request_id for every movement (your payment id, your refund id): a repeat with the same id answers 409 already_applied instead of moving the credit twice, so a retry is always safe. A revoke larger than what is left is refused (revoke_exceeds_credit) and names the remaining figure. Requires the X-Reseller-Customer-Id header.

With X-Reseller-Customer-Id, this creates an invoice on your own payment gateway (connected under Payments in your business dashboard) and returns its pay page: crypto through Heleket or NOWPayments (method: "crypto"), cards through Stripe Checkout or Payoneer Checkout (method: "card"); one live gateway per rail. The page shows your merchant name, the money goes to your account, and when it arrives we credit the customer's store credit automatically: the exact amount, the whole amount when they overpay, and what actually arrived when a crypto invoice closes short. Amounts are whole cents; sub-floor amounts are raised to the method floor ($3 crypto, $10 card) and one invoice is at most $5,000. Send an Idempotency-Key and a retried request returns the same open invoice. No gateway for that method ⇒ 403 deposits_not_available.

An order can pay for itself. POST /orders for a named customer with method: "crypto" or "card" and short credit still answers 402 customer_credit_insufficient, but with payUrl, depositId, chargeCents (the shortfall raised to the rail's minimum) and shortfallCents added. Send the customer to payUrl: when the money lands, the credit is granted and the order is placed automatically under the same Idempotency-Key, a Telegram customer is told in the store's bot, and GET /deposits/{id} shows for_order: true. Without a gateway for that rail the 402 carries no pay page and the customer needs credit first.

The state of a deposit your storefront created, for your own backend to show "payment received". status is awaiting_payment, paid, paid_over, underpaid, expired, cancelled, failed, locked (held by the gateway; nothing credited) or needs_review. credited_cents is what landed on the customer's store credit. Account-level: no customer header needed, and only your own deposits resolve.

With X-Reseller-Customer-Id, the named customer's traffic from the meter: one row per day and one per plan over the last days days (1 to 365, default 30). gbUsed is what was consumed that day; null means no reading exists for that day (a plan's first day, or a gap) and is never zero, and unknownDays counts those. Each day also carries gbTotal (the caps of the plans measured that day) and gbLeft (what they still held at the day's last reading), so how much a customer had and how much is left is a history, not a snapshot. Each plan line carries its cap, the meter at the last reading (gbUsedEnd) and gbLeft. Narrow to one plan with plan_id. What they bought is on GET /orders; this is what they used. Readings land every 30 minutes, one pass after the plan's own figures are synced, so a plan bought in the last hour may have no row yet; for a live figure read the plan itself (GET /plans/{id}).

Account-level (no customer header): what all your customers used per day beside what you sold per day, per product, and the ten customers that used the most, over the last days days. gb_used is the meter, gb_sold is GB on paid orders by the day they were paid, gb_total and gb_left are what the measured plans had and still held at the day's last reading; the four are never mixed into one number. unknown_days counts plan-days without a reading. Readings land every 30 minutes, one pass after each plan's own figures are synced. Snake_case like the other account-level doors.

Every customer on your account, newest first, with identity and credit, the read your backend reconciles against. This is an account-level call: send it without the X-Reseller-Customer-Id header (naming a customer here is refused with a 400 telling you to drop the header).