Noemad Docs
Reseller & procurement
Preserved order lifecycle reference for future operator integrations.
Integration guide · planned capabilities. Model-specific capabilities, usage rates, and x402 upto settlement require backend implementation and validation. The preview runs local samples; documented contracts do not imply live availability.
Internal integration inventory · disabled. The exported frontend included reseller and procurement workflows. Noemad does not expose a live reseller API or customer top-up balance in this preview. Retaining this reference does not enable an internal route.
The public product uses wallet identity and per-inference USDC payments on Monad. An operator may separately purchase capacity from a configured provider; that procurement credential, order, invoice, and ledger must remain outside the customer account surface.
Separate operator procurement from customer payment
| Concern | Owner / boundary |
|---|---|
| Inference API key | Wallet-owned product key; not a procurement credential |
| Procurement credential | Operator secret with a specific provider and role |
| Provider credits | Operator capacity; never returned as a shared customer balance |
| User charge | Metered actual cost from an immutable inference quote |
| Receipt | One owner-scoped product operation; provider invoice remains private |
The source’s account, order, provider-choice, and recovery concepts are preserved below. Quantities, prices, bonus rules, payment rails, expiry, and fulfillment units must come from the actual configured procurement contract. They must not be copied into Noemad retail offers.
Proposed internal order directory
| Method | Reference path | Purpose |
|---|---|---|
| GET | /private/v1/reseller/me | Read credential scope and procurement product terms |
| GET | /private/v1/reseller/payment-providers?quantity=1 | Read eligible payment routes for the intended purchase |
| POST | /private/v1/reseller/orders | Create one intended operator purchase |
| GET | /private/v1/reseller/orders + Idempotency-Key | Recover the original order after a lost create response |
| GET | /private/v1/reseller/orders/{id} | Read preparation, payment, and fulfillment state |
These paths describe an internal compatibility inventory only. A future operator service must explicitly approve its scope and authentication before any route is enabled. The frontend never calls them.
Read terms before creating an order
{
"account": {
"id": "OPERATOR_ACCOUNT_REFERENCE"
},
"product": {
"id": "PROCUREMENT_PRODUCT",
"unit_quantity": "FROM_PROVIDER_CONTRACT",
"price": "FROM_PROVIDER_CONTRACT",
"expiry_policy": "FROM_PROVIDER_CONTRACT"
},
"payment_methods": [
"CONFIGURED_METHODS"
]
}Read the product contract to confirm unit size, price, supported methods, bonus eligibility, and capacity expiry. Do not infer them from an old marketing page. Store the procurement credential in a server secret manager; do not expose it in a browser field or product API response.
Discover and preserve a provider choice
{
"payment_method": "CONFIGURED_METHOD",
"default_provider": 0,
"selection_enabled": true,
"quantity": 1,
"providers": [
{
"id": 0,
"name": "Automatic",
"available": true,
"reason": "eligible"
},
{
"id": 1,
"name": "Provider 1",
"available": true,
"reason": "eligible"
},
{
"id": 2,
"name": "Provider 2",
"available": false,
"reason": "temporarily_unavailable"
}
]
}A stable numeric choice can hide an underlying operator payment route. Zero or omission means the configured automatic policy. A manual route requires both selection_enabled and available to be true. Discovery does not create an invoice, reserve capacity, or guarantee a payment application will accept it.
A manual choice stays fixed through preparation, retries, recovery, and settlement. Never silently fall back to another route. If an older adapter cannot honor manual choice, return an explicit unsupported state and require a deliberate new choice before creation.
One key for one intended purchase
Idempotency-Key: OPERATOR_PURCHASE_STABLE_ID
Content-Type: application/json
{"quantity":1,"payment_method":"CONFIGURED_METHOD","payment_provider":0}Persist the purchase key before create. Scope it to the owner and canonical order request. Retrying the same key and body returns the same order; changing quantity, payment method, or route with that key returns an idempotency conflict.
The archived quantity bound was 1–100, but a new procurement adapter must publish its actual bound. Never assume that a repeated HTTP request is free of side effects when its first outcome is unknown.
Preparing, recovery, and completion
preparing → pending → fulfilled
│
└── expired / cancelled
unknown → recover the same purchase key and order referenceCreate may return HTTP 200 with a payment instruction, or HTTP 202 with payment: null while preparation continues. Save any order ID before polling. A 202 is not a failure and does not authorize a replacement invoice.
If the create response is lost, recover by the original idempotency key. Save any reference included in a 502 or 503, honor Retry-After, and query the same order. The archived workflow uses at least five seconds between preparation polls and a 5–10 second pending interval; an adapter’s actual guidance takes precedence.
Render exact returned payment instructions
A configured procurement method can return token-network instructions or a local payment invoice. Display the exact returned amount, fee, total, merchant, method, and expiry. Do not generate an amount locally from a stale catalog or substitute a different token or network.
For a QR-based invoice, render a validated returned image or encode the returned payload. A ready QR is a pending instruction, not proof of payment. Parse expiry as the contract declares: a timestamp may be epoch seconds, a numeric string, or a timezone-qualified ISO value.
For token payments, verify the returned chain, contract, address, decimals, exact amount, and expiry. These operator procurement methods do not change Noemad’s customer-facing Monad payment contract.
Poll the original order to fulfillment
Continue reading the same owner-scoped order until it is definitively fulfilled, expired, or cancelled. A payment debit or receipt screenshot requires investigation against that original reference. Do not create a replacement invoice just to try another route.
Payment confirmation and provider-capacity fulfillment may be separate steps. Apply fulfillment once and write an auditable ledger reference. Retrieve receipt documents through the documented authenticated history; never construct an undocumented PDF URL from an order ID.
Error handling
| HTTP | Reason | Action |
|---|---|---|
| 400 | invalid_quantity | Correct the amount within the published bound |
| 400 | invalid_payment_method | Use a configured payment method |
| 400 | invalid_idempotency_key | Supply one valid stable purchase key |
| 401 | invalid_credential | Check rotation, revocation, scope, and expiry |
| 404 | order_not_found | Check ownership and the saved original reference |
| 409 | idempotency_conflict | Do not mutate an existing purchase key |
| 503 | selected_provider_unavailable | Preserve the selected route and any order reference |
| 503 | provider_selection_unavailable | Do not assume an unsupported manual choice was honored |
| 502 / 503 | preparation_unavailable | Honor Retry-After and recover the same purchase |
| unknown | payment_outcome_unknown | Reconcile the original reference before any new purchase |
A temporary setup failure is not evidence that the credential is invalid or that no remote invoice exists. Bounded retries, stable identity, and reconciliation are required to avoid duplicate purchases.
Postman and terminal tooling
A maintained integration collection would include account discovery, route discovery, create, recover, and status requests with placeholder credentials. A terminal client should persist state, hide secret input, and separate read-only check from explicit create.
procurement providers --quantity 1
procurement create --key STABLE_PURCHASE_ID --quantity 1 --state order.json
procurement check --state order.json
procurement resume --state order.jsonNo collection, installer, or executable download is advertised until it exists in this project and is tested. The source archive’s missing downloads are not represented as working links.