> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sellauth.com/llms.txt
> Use this file to discover all available pages before exploring further.
# How Delivery Works
> The five delivery types on SellAuth, how each one fulfills an order, and what the buyer receives.
Delivery type is set per product and decides two things: what the buyer receives when payment clears, and how stock is counted. It is picked when you create the product and can be changed later.
| Type | Delivers | Stock |
| - | - | - |
| **Serials** | Items you pre-load, one per buyer | The number of unsold items |
| **Service** | The text you write, either as the product itself or as a note before you fulfill by hand | Set manually, can be unlimited |
| **Dynamic** | Whatever your webhook returns at purchase time | Set manually, can be unlimited |
| **Files** | Downloadable files attached to the variant | Set manually, can be unlimited |
| **Physical** | Nothing automatic, you ship the item | Set manually, can be unlimited |
## Which type to pick
The deciding question is where the thing being sold comes from. Use Serials when it already exists as a list of codes, Dynamic when a program produces it on demand, and Service when the product is text you write once, such as a method or a guide, or work a person does after the sale.
| What you sell | Type | Why |
| - | - | - |
| License keys generated in advance | Serials | They already exist as a list |
| License keys issued per buyer by your own system | Dynamic | Your endpoint mints one at purchase time |
| Pre-made accounts | Serials | One `email:password` line per buyer |
| Discord Nitro gift links | Serials | Each link is single use |
| Gift cards and top up codes | Serials | Fixed codes from a stock list |
| A written method, guide or tutorial | Service | The text you write is the product |
| Any text delivered the same to every buyer | Service | Nothing needs generating or reserving |
| Discord boosts, done by hand | Service | You apply them after the sale |
| Discord boosts, applied by your own bot | Dynamic | Your bot does the work and returns confirmation |
| Game boosting or coaching | Service | The work is manual and takes time |
| Design or editing work | Service | Delivered by a person |
| Cheats or software with a per-user key | Dynamic | The key comes from your licensing system |
| Cheats or software with a shared key pool | Serials | The keys already exist |
| E-books, templates, asset packs | Files | The same file goes to every buyer |
| Subscriptions to an external service | Serials or Dynamic | Serials for pre-made logins, Dynamic if you provision per buyer. Add [recurring billing](/guides/subscriptions) on the variant |
| Merch, hardware, anything shipped | Physical | It leaves your hands physically |
Three things to know before you commit:
* **Serials run out, Service does not.** If every buyer must receive something different, such as their own key or account, that is Serials and your stock depletes. If every buyer receives the same thing, such as a method or a guide, that is Service and it sells indefinitely.
* **Service only costs you time with manual fulfillment on.** Left off, the text delivers itself and needs no attention at all.
* **Dynamic is the only type that needs code.** It is also the most capable. If nobody is going to build and host the endpoint, choose Service instead.
Delivery type can be changed later, so an early wrong guess is not permanent.
## Serials
For anything that exists as a list of codes: license keys, accounts, gift cards, Nitro links, top up codes. You paste the items in, and each sale hands one to the buyer and removes it from stock.
Covered in full in [Serials and Keys](/guides/serials-and-keys).
## Service
Service covers everything delivered by the text you write in the product's **instructions** field, rather than from a stock list, a file or a webhook. It works two ways, and the **Requires manual fulfillment** checkbox decides which.
### Selling text itself
Leave manual fulfillment **off** and the instructions are the product. The invoice completes the moment payment clears, and every buyer receives the same text immediately.
This is how written products are sold: a method, a guide, a tutorial, a walkthrough, a list of settings, a link to something you host elsewhere. Nothing needs generating and nothing needs reserving, so stock is usually set to unlimited and the product sells without any involvement from you.
Selling a "method" or any other block of text is Service, not Serials. Serials hands each buyer a different line from a list and runs out. Service gives every buyer the same text and never runs out.
Write the text in **Instructions**, or in a variant's **Override Instructions** where tiers differ. Formatting and links are preserved, so a method with steps and screenshots links reads as you wrote it.
### Work you do after the sale
Turn manual fulfillment **on** when the buyer is paying for work you carry out yourself: custom design, boosting, coaching, account work.
The invoice stays paid but open until you close it, and the buyer can follow its progress. From the invoice page it moves through **Mark as In Progress** and then **Mark as Completed**.
Both steps take a message to the customer, shown on their checkout page and included in the email. On **In Progress** the email is optional, with a checkbox for it. On **Mark as Completed** the customer is always emailed.
Use it whenever the work takes time, so the buyer sees an accurate state instead of an invoice marked completed before anything has happened.
## Dynamic
At the moment payment completes, SellAuth sends a POST request to a URL you control, and delivers whatever your server returns. Use it when the thing being sold is generated on demand, such as a key issued by your own licensing system.
Your endpoint should return HTTP 200 with plain text, one deliverable per line. Requests carry an HMAC-SHA256 signature in the `X-Signature` header, and the secret for verifying it is under [**Miscellaneous**](https://dash.sellauth.com/shop#miscellaneous) in shop settings.
Full request format, payload example and verification steps are in [Dynamic Delivery](/developers/dynamic-delivery).
If a dynamic delivery fails, the invoice page has a **Redo Delivery** action on the affected item, which calls your endpoint again once it is fixed.
### Dynamic or Service
Both cover work that happens after the sale. The difference is who does it.
Dynamic suits anything a program can complete in seconds: minting a license, calling an API, running a bot that applies Discord boosts. The buyer is served immediately and you are not involved.
Service suits anything needing a person, and anything where your automation is not built yet. It is also the safer starting point: sell with Service while you are still writing the endpoint, then switch the product to Dynamic once it works.
## Files
Uploads attached to a variant, delivered as downloads after purchase. Suitable for e-books, templates, packs and assets.
Files are managed under **Downloadable Files** and then attached per variant, so the same file can serve several products without uploading it again.
How many files you can store, and the maximum size of each one, depend on your plan.
## Physical
Nothing is delivered automatically. The buyer pays, you ship, and you record what happened on the order.
Physical products need at least one shipping zone before they can be bought, and always collect a billing address. See [Physical Products](/guides/physical-products).
## Instructions
Every product has an **Instructions** field, shown on the checkout page and in the delivery email once payment completes. What it should contain depends on the delivery type:
| Type | What to write |
| - | - |
| Serials | How to redeem or use the delivered item |
| Service | The delivery itself when manual fulfillment is off, so this field holds the entire product. Otherwise, what the buyer gets and what happens next |
| Dynamic | Context for whatever your webhook returns |
| Files | Anything the buyer needs alongside the download |
| Physical | Shipping expectations and what happens next |
Instructions can be overridden per variant, which is useful when a lifetime tier is redeemed differently from a monthly one.
## Thank you message
Products also have a separate **Thank You Message**, shown on the checkout page next to the instructions once payment completes. It exists so the pleasantries stay out of the redemption steps: a buyer scanning for how to use what they bought should not have to read past a paragraph of thanks to find it.
Unlike instructions it cannot be overridden per variant, since the same note usually suits every tier. If you want it identical across your catalogue, select your products in the product list and use **Bulk Edit, Thank You Message**.
Where it appears relative to the other blocks is up to you. See [checkout settings](/guides/checkout#completed-page).
## Extras that run on delivery
**Discord auto join and auto role** adds the buyer to a server and assigns roles when their payment clears, configured per variant.
**Redirect URL** sends the buyer to a page of your choice after payment. If an invoice contains several items with redirect URLs, only the first is used.
## When delivery goes wrong
**Out of stock.** The payment succeeded but stock ran out first. The buyer sees your out of stock message, and the invoice sits at **Out of Stock** until you restock and process it.
**Partially completed.** Some line items delivered and others did not. Open the order and retry the failed item.
**Wrong item delivered.** The invoice page can swap what was sent, either **Replace from Stock** or **Replace Manually**. See [replacing a delivered item](/guides/serials-and-keys#replacing-a-delivered-item).
**The buyer says nothing arrived.** Check the email address on the invoice first, since a typo there is the most common cause. The invoice page can resend the delivery email to a corrected address.
## Next steps
Setting up the product that gets delivered.
Loading stock and choosing which item goes out.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.