Skip to content

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

ConcernOwner / boundary
Inference API keyWallet-owned product key; not a procurement credential
Procurement credentialOperator secret with a specific provider and role
Provider creditsOperator capacity; never returned as a shared customer balance
User chargeMetered actual cost from an immutable inference quote
ReceiptOne 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

MethodReference pathPurpose
GET/private/v1/reseller/meRead credential scope and procurement product terms
GET/private/v1/reseller/payment-providers?quantity=1Read eligible payment routes for the intended purchase
POST/private/v1/reseller/ordersCreate one intended operator purchase
GET/private/v1/reseller/orders + Idempotency-KeyRecover 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

json
{
  "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

json
{
  "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

Creation contract
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

Order lifecycle reference
preparing → pending → fulfilled
             │
             └── expired / cancelled
unknown → recover the same purchase key and order reference

Create 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

HTTPReasonAction
400invalid_quantityCorrect the amount within the published bound
400invalid_payment_methodUse a configured payment method
400invalid_idempotency_keySupply one valid stable purchase key
401invalid_credentialCheck rotation, revocation, scope, and expiry
404order_not_foundCheck ownership and the saved original reference
409idempotency_conflictDo not mutate an existing purchase key
503selected_provider_unavailablePreserve the selected route and any order reference
503provider_selection_unavailableDo not assume an unsupported manual choice was honored
502 / 503preparation_unavailableHonor Retry-After and recover the same purchase
unknownpayment_outcome_unknownReconcile 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.

Planned CLI interface — not a published command
procurement providers --quantity 1
procurement create --key STABLE_PURCHASE_ID --quantity 1 --state order.json
procurement check --state order.json
procurement resume --state order.json

No 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.