> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komerza.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Reselling

> Sell another store's products as your own, drawing their stock at the moment you make a sale.

## Overview

Reselling lets you list another Komerza store's products in your own store. When one of your customers buys, Komerza draws a unit from the supplier's stock, charges it to a balance you hold with them, and hands the delivery straight to your customer.

You never hold their stock, and you never front the money for units you have not sold.

<Note>
  If your own store is on Komerza, none of this page applies to you. Your draws
  are served internally and there is nothing to configure — set it all up from
  **Reselling** in your dashboard instead.
</Note>

This guide is for **off-platform resellers**: you sell somewhere other than Komerza.

## Two ways to get stock

Both start the same way: apply to the supplier's reseller programme from their customer dashboard, get approved, and fund a balance with them. Stock is paid for out of that balance either way.

<CardGroup cols={2}>
  <Card title="Buy up front" icon="box">
    Buy a quantity now and download it as a text file. Nothing to build — the
    units are yours to sell wherever you like.
  </Card>

  <Card title="Draw per sale" icon="bolt">
    Your storefront calls Komerza at the moment it makes a sale, and gets a unit
    back. Needs a store that can call out mid-checkout.
  </Card>
</CardGroup>

You can use both, and most people start with the first.

## Buying up front

From the supplier's customer dashboard, under **Reselling**: pick a product, choose a quantity, and confirm. The cost comes out of your balance and the units come straight back, downloadable as a text file with one unit per line.

Nothing about this needs an integration. If your own shop is a Discord bot, a spreadsheet, or a marketplace listing, this is the whole thing.

<Note>
  Suppliers can turn this off, in which case every sale has to draw at the time
  through a delivery URL. It is on by default.
</Note>

Two limits worth knowing:

* **Text-delivered products only.** A file-delivered product cannot be handed over as a downloadable unit, though it still sells fine drawn per sale.
* **The supplier's delivery has to answer per unit.** If it returns one response for the whole order, one unit arrives and the rest is refunded to your balance. Suppliers wanting to sell in bulk should return an `items` array — see [Dynamic Delivery](/guides/dynamic-delivery#honouring-quantity).

If fewer units arrive than you paid for, the difference goes back to your balance automatically. You are never charged for stock that did not turn up.

## Drawing per sale

The rest of this page covers the other route: your store calls a delivery URL when it makes a sale, and Komerza draws a unit from the supplier at that moment.

1. **You generate a delivery URL** and paste it into your own product's delivery configuration.
2. **A customer buys** from you. Your store calls the delivery URL, Komerza draws a unit from the supplier, and returns it.

## Your delivery URL

Generate it from the supplier's customer dashboard, under **Reselling**. It looks like this:

```
https://m-api.komerza.com/reseller/delivery/{token}
```

<Warning>
  **The URL is the credential.** Anyone who has it can draw stock and spend your
  balance with that supplier. Treat it like a password: store it where you keep
  secrets, never commit it, and never paste it into a support ticket or a
  screenshot.
</Warning>

Komerza keeps only a hash of the token, so it is shown once and cannot be looked up again. If you lose it or it leaks, generate a new one — the previous URL stops working immediately.

### Why there is no signature

Delivery calls are not signed. Your store signs its outbound requests with its own secret, or does not sign at all, and Komerza has no way to verify a signature it did not issue the key for. Requiring one would mean nobody could integrate.

The unguessable token takes its place. That is a deliberate trade: it is simpler to integrate and weaker than a signature, which is why the token is 256 bits, is never returned twice, and can be replaced at any time.

## The request

Your store sends a `POST` with the same body Komerza's own dynamic delivery uses, so if your platform already supports dynamic delivery you can point it at this URL and change nothing else.

```json theme={null}
{
  "storeId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "customerId": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
  "lineItemId": "9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d",
  "productId": "1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d",
  "variantId": "8f7e6d5c-4b3a-2918-7654-3210fedcba98",
  "quantity": 1,
  "order": { "...": "the full order, as in dynamic delivery" }
}
```

<ParamField body="variantId" type="string" required>
  The variant **on your store** that was sold. Komerza maps it to the supplier's
  variant through the listing you configured.
</ParamField>

<ParamField body="lineItemId" type="string" required>
  Your line item's id. This is the idempotency key — see [Retries](#retries).
</ParamField>

<ParamField body="quantity" type="integer" required>
  How many units were sold. The response contains one entry per unit.
</ParamField>

## The response

`200 OK` with one entry per unit:

```json theme={null}
{
  "items": ["LICENSE-KEY-ABC123", "LICENSE-KEY-DEF456"],
  "sourceOrderId": "5f3a8b2c-1d4e-5f6a-7b8c-9d0e1f2a3b4c",
  "cost": 14.0,
  "currency": "USD",
  "sampled": 0
}
```

<ResponseField name="items" type="string[]">
  The delivered units, one entry per unit sold. Hand these to your customer.
</ResponseField>

<ResponseField name="sourceOrderId" type="string">
  The order raised on the supplier's store. Quote it if you need to chase them
  about a delivery.
</ResponseField>

<ResponseField name="cost" type="number">
  What was charged to your balance, in the supplier's currency.
</ResponseField>

<ResponseField name="sampled" type="integer">
  Units the supplier gave you free as a sample. These cost nothing.
</ResponseField>

The `items` shape is the same one Komerza's dynamic delivery accepts, so a Komerza store consuming this needs no translation.

## Retries

`lineItemId` is the idempotency key. Calling again with the same one returns the units already drawn for it rather than drawing more — so a retry after a timeout is safe and cannot double-charge your balance.

Use a stable id from your own order. A fresh id on each attempt reads as a separate sale and draws again.

## Failures

<ResponseField name="402 Payment Required" type="error">
  The draw was refused. The body carries a short reason.
</ResponseField>

Responses are deliberately terse: the caller is a storefront, and the detail of *why* a draw failed is not something to expose there. The full reason is in your reseller panel on the supplier's store.

Common causes:

<AccordionGroup>
  <Accordion title="Your balance is too low">
    Top it up from the supplier's customer dashboard. Draws are charged at the
    moment of sale, so a balance that runs out mid-day stops deliveries.
  </Accordion>

  <Accordion title="The supplier is out of stock">
    Nothing you can fix. Consider buying stock up front if they allow it, which
    also protects you from them running out.
  </Accordion>

  <Accordion title="Your access was revoked">
    The supplier withdrew it. Stock you already bought outright is still yours.
  </Accordion>

  <Accordion title="The product is no longer offered">
    They removed it from their reseller catalogue, or paused it.
  </Accordion>

  <Accordion title="The price rose above your ceiling">
    If you set a maximum cost per unit on the listing, a supplier price rise
    past it stops draws rather than quietly eating your margin.
  </Accordion>
</AccordionGroup>

## Chains

A product can be resold through more than one store, but not indefinitely — a draw is refused once it has passed through **two** stores. Komerza tracks this with a header it adds on each hop:

```
X-Komerza-Resell-Depth: 1
```

You do not need to set it. If you are forwarding a draw you received, pass the header through so the count stays accurate.

## Volume pricing

Suppliers can set price breaks for buying in quantity. They apply to both routes, but they are far easier to reach by buying up front, since a per-sale draw is usually for one unit.

The highest threshold your quantity clears wins, and terms set on a specific product beat catalogue-wide ones. A price break worse than the everyday reseller price is ignored rather than charged, so a supplier's typo can never make buying in bulk cost more than buying one at a time.