API reference

The OrderDen public API is a REST API over everything the app does — clients, the item catalog, quotes, orders and shipments, invoices and payments, vendors, purchases, spreadsheet imports, the activity trail, dashboard data, search and settings. It's included in every plan, Free included — unmetered by volume, with a per-minute rate per key (see Plans & billing) — and every new OrderDen feature ships with API coverage.

Try it live: the interactive API explorer renders every endpoint with parameters and schemas — click Authorize, paste an API key, and run requests against your own workspace. The machine-readable OpenAPI specification behind it also works with Postman, code generators and other OpenAPI tooling.

Authentication

Create a key in Company Settings → API keys (owners/admins). The secret — od_live_ followed by 40 hex characters — is shown once; only its hash is stored. Send it as a bearer token on every request:

curl -s https://your-domain.example/api/v1/clients \
  -H "Authorization: Bearer od_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

A key acts in one workspace and can be revoked at any time. Writes made with a key appear in the activity trail attributed to the key by name.

A key carries the permissions of whoever created it, read fresh on every request — so taking somebody's access away takes away what their keys can do too. A key made by somebody without See costs and margin gets responses with every cost, margin, fee and profit field removed, not zeroed; a key without Create and edit documents gets a 403 on the writes that need it. A key whose creator has left the workspace falls back to read-only. Call GET /me first from a new integration and read what it says rather than discovering a missing field as a gap. See Roles, permissions, two-factor and sessions.

There is no monthly request quota. The one limit is a per-minute rate per key — 60 a minute on Free, 300 on OrderDen — which exists to catch a runaway script rather than to be bought back. GET /billing reports what your workspace has been calling and the rate it may call at.

Conventions

• Base path /api/v1; JSON in and out.
• Success responses wrap the payload: { "data": … }; list endpoints add "meta": { total, page, pageSize, pageCount } and take ?page=…&pageSize=… plus per-resource filters.
• Sorting: every list takes ?sort=field or ?sort=field:asc / field:desc (e.g. sort=total:desc), restricted to a per-list set of sortable fields — an unknown field is rejected with a message naming the valid ones. Omitting the direction uses the field's natural default (text A→Z, dates and amounts newest/largest first).
• CSV export: every list also takes ?format=csv, which streams the entire filtered result set (paging is ignored) as a CSV download in the current sort order. columns= (comma-separated ids) picks and orders the columns; omit it for all columns.
• Errors are { "error": { "code", "message", "details"? } } with matching HTTP status — 400 validation, 401 bad/missing key, 402 plan limit reached (a free workspace has issued all 50 of its invoices, or its seats are full; details.limit is invoices or seats), 403 forbidden (the key's permissions don't cover this; details.permission names the flag), 404 not found, 409 conflict (the write clashes with the resource's current state — a duplicate number, an illegal status transition, a locked document), 422 unprocessable (a business rule against the data, e.g. shipping more than remains open), 429 rate limited.
• Polling: every list takes ?updatedSince=<ISO timestamp> and returns rows changed at or since that instant. Inclusive — store the newest updatedAt you saw and send it back, and you see that one row again rather than missing one written in the same millisecond.
• Retrying a write: send an Idempotency-Key header (any unique string) on a POST, PUT, PATCH or DELETE. Retrying with the same key replays the first response for 24 hours and creates nothing twice; the same key with a different body is a 409, because that is a bug in the caller.
• Rate-limit headers on every response: X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset (unix seconds).
• Money is decimal strings ("149.50") everywhere, including figures the server works out rather than reads off a record — a report's revenue and margin, a dashboard money stat, a project rollup, a price suggestion, a stock valuation. Unit costs carry the stock ledger's four decimals instead of two ("6.1000"). Percentages, counts and quantities stay numbers: they are not amounts. Dates are ISO-8601. Partial updates use PATCH. Document numbers are server-assigned from your configured formats when number is omitted; quotes, orders, invoices, purchases and payments all accept one of your own on create, and PATCH renames it (409 when taken). Derived statuses (fulfilment, payment states) can't be set directly.
• Lines: lines may be empty on a quote, order or invoice as long as the document still comes to more than zero — freight or tax billed on its own. A document that would come to nothing with no lines is rejected 422.
• Line ids on an update: every line comes back with an id. When a PATCH sends lines, send those ids back with them: a line carrying its id is rewritten in place, one without is written as new, and one whose id you stop sending is deleted. That is what keeps billed time and expenses attached to the invoice line they were billed on, so you can reorder and edit freely as long as the ids travel with their lines. Drop them and every line is read as new, which detaches that work and hands it back to Ready to bill. An id that is not a line on that document, or the same one sent twice, is rejected 422; id is ignored on POST, so a document read back and posted as a copy needs nothing stripped.
• Discounts: documents and their lines take an optional discountType (PERCENT or AMOUNT) with a discountValue — both or neither; discountType: null on PATCH clears it. Line discounts come off quantity × unitPrice, the document discount off subtotal before tax, and responses add the resolved discountAmount at both levels.
• Cost basis: quote, order and invoice lines return a read-only unitCost — the catalog item's unit cost as of when the line was written (null when unknown), snapshotted on create and whenever lines are replaced, and carried unchanged through convert, invoice and duplicate. A line with no itemId may set unitCost explicitly; on an item line it is ignored in favour of the catalog.
• Gross margin: every order returns a read-only margin — net revenue (line totals after discounts plus shippingAmount, tax excluded) against the cost basis (each line's quantity × unitCost plus every recorded shipment cost), as margin and marginPercent, per line under lines, with coverage saying how many lines and shipments have a cost. A line or shipment with no cost is unknown, never zero: it is left out and margin is null when no line has one.
• Sales documents require billTo/shipTo on create and carry publicNotes (client-facing) and notes (internal), plus an optional customerPo (the client's own purchase-order reference, max 100 characters) that is echoed on every printed, emailed and shared copy.
• Orders additionally carry requestedDate (what the client asked for) and promisedDate (what you committed to). Both are optional dates, cleared by sending null, and promisedDate drives the Orders due this week dashboard widget.

Endpoints

Custom fields & bulk actions

invoice on orders closes each one out as its own draft invoice, deducting what has already been paid on it. One per order, never a consolidated bill; drafts rather than emails. A draft order, or one already invoiced, fails on its own row.

Clients, items, orders, quotes and invoices accept and return customFields (a merge: sending one field never clears the others) and filter on cf.<key> — ?cf.account_no=4471, ?cf.notes=contains:gate, ?cf.visit=after:2026-01-01.

Catalog tree, tags & the archive

Those six list endpoints take archived=true|false|all. Deleting a document past DRAFT returns 409 and names archive instead. Items take categoryId and filter by it (children included) or uncategorised=true.

Setup checklist, starter kits & opening balances

vocabulary changes labels in the app only — no field name here depends on it, so an integration is never industry-specific.

Webhooks

Deliveries are signed X-OrderDen-Signature: t=<unix>,v1=<hmac-sha256(secret, t + "." + body)> and retried after 1 minute, 5 minutes, 30 minutes, 2 hours and 12 hours. Full details, including the verification code, are in Webhooks & automation.

Team & access

Nobody grants access they do not hold themselves, and the owner's row is not editable here. Every role uses a seat, so POST /invitations returns 402 when the plan's seats are full; a role change never does, because it never changes what the workspace pays. There is no POST /members: people join by accepting an invitation.

Organization, dashboard & activity

Reports

Every report takes range (the dashboard presets; default this_month) with from/to for range=custom, and ?format=csv (with the list exports' columns= picker) streams the report's rows. The two tax-time reports are the exception: they take a plain from/to pair of calendar dates, because a financial year is a pair of days a filing names. See the Reports guide and Tax time for what each one measures.

Clients

A merge repoints every row that references a merged client — every document, payment, address, contact, portal account, project, file and activity entry — onto keepId in one transaction, applies fieldChoices to the survivor (tags are combined, credit balances add up), and archives the emptied records rather than deleting them. Ten at a time at most, and 409 rather than a half-merge when two of them hold a portal sign-in for the same address. See Clients.

Items

Stock

See Inventory & stock for what the figures mean.

Inventory and bins

Items and inventory are the same rows answering different questions. /items is the catalogue; these are the shelf.

A bin is free text — "A3", "top shelf, left" — and a thing can be in several at one place. Location stays the coarse where (studio, lock-up, van); the bin is the fine one. No bin carries a quantity: the ledger counts stock per location, so bins say where to look, not how many are in each.

See Bins.

Stocktakes

See Counting stock.

Barcodes & labels

Items and variants accept barcode and barcodeType (EAN13, UPCA, CODE128, QR); leave the type out and it is inferred. A code belongs to exactly one thing — a duplicate is a 409 naming what already has it.

See Barcodes and labels.

Locations

Orders accept locationId — the shelf the order is picked from. See Inventory & stock.

Enquiries

The form's switch and sentences are enquiryFormEnabled, enquiryFormIntro and enquiryFormThanks on /settings/templates. See Enquiries.

Purchase orders from clients

Submitting one is the portal's own, not /api/v1: only a signed-in portal client can write one. The switch is portalPoEnabled on /settings/templates, and portalPoEnabled on a client is the per-client exception. See The client portal.

Quotes

Quote lines also accept isOptional, isSelected, optionGroup and optionGroupLabel; the quote's total counts the selected lines alone and exposes optionalTotal (what is on offer and not taken, ex tax) and selectionLockedAt. See Quotes.

Quote templates

Recurring invoices, cards on file and late fees

Saving a payment method is deliberately not an API operation — it needs the processor's own form in front of a person. See Recurring invoices.

Client portal

Signing in is not an API operation: a magic link goes to the client's inbox, which is the point of it. See Client portal.

Statements of account

Leaving one client off the automatic run is a client field — see Statements of account.

Orders & shipments

Print batches

A stack of documents rendered as one PDF, without holding a request open while it happens. Laying out forty packing slips or merging forty carrier labels is seconds of solid CPU; it runs on the worker and you poll for the file.

An id that cannot be rendered — a shipment with no label bought, an order with nothing to pack — comes back in missing rather than failing the batch: thirty-nine slips are better than none.

Shipping labels

Buying postage through the workspace's own EasyPost account. Rating an order is a question, not a write: ask it as often as you like. Buying a label records the shipment with what the postage cost — which is what makes the order's margin the real one — and keeps the PDF.

Millimetres and grams throughout, because that is what the columns hold; money is in the account's own currency.

Price lists

Named sheets of prices, with the minimum and case pack each line is sold on. See Wholesale and retail pricing.

Clients accept priceListId, and a document line accepts one too — a one-off trade price on an otherwise retail document. A line left at zero takes what the lists say; a price you send is kept as sent.

Pricing

What to charge, and what a price actually leaves you. Read-only except for the one write that sets a price, which lands in the item's history saying where the number came from.

The target is a margin — what is left after the goods and the postage are paid for — not a markup. Postage you charge is revenue and postage you pay is a cost, so absorbing it moves the answer.

Tax rates & groups

The workspace's tax settings (Company Settings → Taxes). A rate is one named percentage; a group charges one or more of them together, in position order, and is what a document line points at. Creating a rate also creates the single-rate group that makes it pickable, so /tax-groups is the list to read when populating a picker.

On documents. Every line payload takes taxGroupId (omit it to fall back to the item's default and then the workspace's; send null for no tax) and taxable (false leaves the line out of tax entirely). Documents take shippingTaxGroupId for tax on the shipping charge — null, the default, leaves shipping untaxed. Responses carry taxAmount plus a taxBreakdown: [{ "name", "rate", "amount" }], one entry per rate the document charged. Each line carries the taxRate (the group's effective combined percentage) and taxAmount snapshotted when it was written. A client with taxExempt: true is never charged, whatever a line asks for.

Carriers

The workspace's shipping-carrier list (Company Settings → Carriers). Shipment.carrier references a carrier by name; a carrier's trackingUrlTemplate (containing a {tracking} token) is what turns tracking numbers into links.

Invoices & payments

Payments on an invoice carry number (the receipt number), method, methodNote, source (MANUAL · ONLINE · IMPORTED), feeAmount and netAmount (the processor's cut and what reached the workspace; null on manual payments), refundedAmount and their refunds. An invoice settled in full also carries paidAt — the date of the payment that cleared it, null on anything unpaid or reopened by a refund; it is sortable as sort=paidDate and exports as the paidDate column.

Credit notes, refunds and write-offs

Correcting a sale without pretending it never happened. See Credit notes.

POST /payments takes allocations[] — [{ invoiceId, amount }] — so one payment can settle several invoices, plus autoAllocate to spread the rest over the client's open invoices oldest-first. Whatever is left over becomes their credit. Clients carry creditBalance.

Payment receipts

Payments as their own collection

The same records read the other way round — every payment in the workspace, not one invoice's.

Rows carry the invoice they settle, when they settle one, with its number, currency and total, plus that invoice's client. A payment against no invoice is client credit. Deleting and refunding stay on the invoice's own sub-resource above.

Share links & attachments

GET/POST/DELETE /{doc}/{id}/share-link on quotes, orders and invoices — create (or rotate with { "rotate": true }), read and revoke the document's portal link.

GET/POST /{parent}/{id}/attachments on clients, quotes, orders, invoices, purchases and vendors (base64 data, 10 MB cap), plus GET /attachments/{id}, GET /attachments/{id}/download and DELETE /attachments/{id}.

Two things happen to an upload on the way in. An image is downscaled — capped at 2,000 px on its long edge and re-encoded, keeping its filename and its content type; PDFs and anything that is not a photograph pass through untouched, so the bytes you get back from /download may be smaller than the bytes you sent. And a workspace has an hourly upload cap on top of the per-file size limit; going past it returns 409 conflict naming the limit and when it resets.

Clearing out old attachments

Only attachments are removed. The client, quote, order, invoice, purchase, expense or project each file hung off is untouched. Catalog item photographs and the organization logo are never in scope, the cutoff must be at least 30 days ago, and one run packages at most 5,000 files or 512 MB, whichever comes first. Owners and admins only. See Your data.

Variants, kits & item images

Document lines accept variantId and personalization; a line naming an item with variants must carry one (422 otherwise). Stock lives on the variant, so the adjust and opening-stock calls take a variantId too — see Items & pricing.

Materials, units, variables & recipes

The costing side. Materials are catalog items of type MATERIAL, so every /items endpoint works on them too; these routes scope the list and force the type. See Materials, recipes and what things cost.

Items carry unitId, costSource (MANUAL/RECIPE/PURCHASES) and the read-only recipeUnitCost; GET /items?salesOnly=true leaves materials out.

Production runs

Making stock rather than buying it. A run scales the item's recipe to the quantity being made; nothing moves on the stock ledger until it completes, which is what makes a planned run free to cancel. Completing consumes the materials, books any waste as an adjustment, puts the finished batch on the shelf at what it cost, and freezes that cost so a later price change never rewrites it. See Production.

Items carry madeToOrder (confirming an order opens a planned run against each of its lines) and curingDays (how long a finished batch sits before it can be sold — curing stock is on hand but not available).

Vendors & purchases

Purchase lines accept itemId (what the line buys), unitOfPurchase and conversionFactor; the header accepts allocateExtraCosts. Receiving a line that names a stock-tracked item adds quantity × conversionFactor to stock at its landed cost, which moves the item's average — see Vendors & purchasing. A purchase's spend category is categoryId, from the same shared list expenses use.

Spending

Read-only. The two records stay two records: receiving a purchase writes a receipt, a stock movement and a new average cost, and an expense never touches stock — so creating and editing either still goes to /purchases or /expenses.

See Spending.

Projects & time

Quotes, orders, invoices, purchases and expenses accept a projectId, and document lines accept a kind (ITEM, LABOUR, MATERIAL, EXPENSE, TEXT). See Projects.

Expenses

| POST | /expenses/from-image | A photograph in, a drafted expense out (multipart file, or base64 JSON) | | POST | /expenses/{id}/confirm | Agree with the draft; an empty body confirms it as read | | GET/PUT | /settings/inbound-email | The workspace's receipts-in address; { enabled: false } silences it | | POST | /settings/inbound-email/rotate | Replace it — the old one stops accepting mail |

A drafted expense is a suggestion: confirmedAt is what a person set, and needsReview=true lists the drafts nobody has agreed with yet. Spend is counted net of the tax on it (amount - taxAmount), and a re-billed line is priced at that net figure plus markupPercent. See Expenses.

Accounting export

The zip holds sales, credits, payments, bills, expenses, fees and journal CSVs. The journal balances every day in the period — debits equal credits, checked before anything is written. Generating refuses with 422 unmapped_accounts while anything has no account, listing what is missing; acceptSuspense: true generates anyway into account 9999. See handing the numbers to your accountant.

Imports (CSV)

Everything the import wizard does. A file arrives either as multipart/form-data with a file part (plus kind, and optional mapping as a JSON part and duplicatePolicy) or as JSON with the CSV in csv — or as already-parsed rows of column → value, for a script with no file to hand. Omit mapping and the columns are matched by their headings, exactly as the wizard pre-fills them.

The ten kinds, roughly in the order to do them: clients, items, materials, vendors, price-list, opening-stock, orders, invoices, payments, expenses. (open-invoices is the old name for invoices and still works.) A preview returns the kind's fields — name, label, type, required, an example and a line of help — so a script can build a file without hard-coding column names.

Rows are created through the same services as the rest of the API, so validation, numbering and the activity trail are identical; a rejected row never stops the run. Each batch reports createdCount, updatedCount, skippedCount and errorCount, and keeps createdIds — the undo list. Undo covers created records only; rows that updated an existing record are not rewound.

Two behaviours are worth knowing before you script against it. opening-stock creates nothing — it sets balances, so re-importing a corrected count books the difference rather than doubling the shelf. And imported history is never counted: opening-balance invoices do not touch the free 50, because a migration is not selling you did here.

Payment terms, deposits and schedules

GET/POST /payment-terms and GET/PUT/DELETE /payment-terms/{id} manage the workspace's named terms. A term says what is wanted up front — a percentage or a fixed amount, never both — and when the balance falls due (ON_INVOICE, NET_DAYS, ON_DELIVERY or ON_COMPLETION; the last two are events, so an invoice raised under them starts without a due date).

Quotes accept paymentTermId, depositRequired, depositPercent and depositFixed, and report depositAmount. Accepting a quote raises a DEPOSIT invoice for it, idempotently.

GET/PUT /orders/{id}/schedule reads and replaces the instalments agreed for a project. A schedule made entirely of percentages must add up to 100; mix in a fixed amount and that check stops applying. A step already invoiced cannot be removed or re-priced. POST /orders/{id}/schedule/{stepId}/invoice turns a stage into its own PROGRESS invoice. The money a schedule reports — contractTotal, scheduled, invoiced, remainingToInvoice and each step's amount and value — comes back as decimal strings like every other amount; percent stays a number.

POST /orders/{id}/prepayment-invoice takes money for an order before anybody has billed for it: a DEPOSIT invoice for what is left of the order, which the final invoice later deducts rather than billing twice. Idempotent on the order, and what the portal's pay button on an order link calls.

POST /orders/{id}/final-invoice closes the project out: the whole contract, less every deposit and progress payment already paid on it, deducted as its own negative line and never taxed again. Invoices expose kind, appliedDeposits and balance.

POST /invoices/combined takes { orderIds, status? } and closes several of one client's orders out on a single invoice — the trade account fulfilled five times in a week that would rather pay once than chase five references. Each order's lines, shipping and paid deposits are worked out on their own and then added up, so the combined bill charges exactly what the separate ones would have. order is null on it and billedOrders names each order with its own share of the total; those shares are what each order's invoiced figure counts, so five orders on one bill are attributed once each rather than five times over.

It refuses (422) where the orders cannot share a document, naming them: a whole-document discount (a discount on the lines is fine), a payment schedule, different projects, different currencies, different tax-inclusive pricing, or shipping at two different tax groups. A combined invoice counts as one against the Free plan's lifetime fifty, because it is one invoice raised.

For a whole list at once, POST /orders/bulk with action: "invoice" and payload.combine: true does the same per client: a client with one order in the selection gets an ordinary invoice, and a group that cannot be combined fails every order in it with the reason while the other clients' groups go through.

See Deposits, instalments and final invoices.

Signatures on quotes

Quotes accept requireSignature and termsText (Markdown, snapshotted onto the quote) and expose the signature they carry.

GET /quotes/{id}/signature reads it; POST /quotes/{id}/signature records one taken in person — signerName, signerEmail, method (TYPED or DRAWN), a base64 PNG image for a drawn one, and consented: true. The hash is never taken from the request: the server fingerprints the quote as it stands, so a signature always points at what the workspace actually has. One document, one signature — a second is a 409.

The fingerprint is over the document's content (number, client, every line, the money, the terms), not the PDF bytes, so re-rendering never invalidates it and a real edit always does.

Changing what was agreed means editing the order the quote became — PUT /orders/{id} moves its lines, its money and the tax on them together, and the order's history records what changed.

See Signatures on quotes.

Reminders, follow-ups and email templates

GET/PUT /settings/reminders reads and replaces the chasing schedule: the steps for invoices and quotes, the send hour (local to the workspace), skipWeekends, the master pauseAll, and the daily summary's hour. A step is { key, offsetDays, enabled, templateKey }; its key is permanent, because the reminder log points at it forever.

GET /email-templates lists every letter the app sends on your behalf; GET/PUT/DELETE /email-templates/{key} reads, replaces and resets one, and POST /email-templates/{key}/test posts you a specimen filled in with a sample client and invoice. The body is Markdown with {{…}} variables; one the document does not carry renders blank.

GET/PUT /invoices/{id}/reminders and GET/PUT /quotes/{id}/follow-ups report when the next one is due and everything already sent, and pause chasing on that one document. POST .../reminders/send and POST .../follow-ups/send send one immediately — recorded under its own manual-… key, so a scheduled step is never consumed by it.

Every send is recorded against (document, step), so a client is never chased twice for the same step however many times the worker runs. Chasing stops by itself when the invoice is settled or the quote answered.

See Reminders, follow-ups and status emails.

Push notifications

See OrderDen on your phone.

Notifications

GET /notifications?userId=… is one member's bell menu — { items: [{ id, kind, title, body, href, readAt, createdAt }], unread }, newest first, with unreadOnly and limit — and PUT /notifications/{id}/read with { userId } marks a row read (or unread with read: false).

Settings

GET/PUT /settings/notifications reads and saves what reaches one member, in the app and by email — preferences are per member and a key acts as the whole workspace, so userId names the member (a query parameter on GET, in the body on PUT): { userId, preferences: [{ kind, email, inApp }] }. A kind left out keeps its value.

GET/PUT /settings/templates (document design, its major and minor accent colours, footer — plus quoteFooter, invoiceFooter and purchaseFooter, each blank meaning the shared one — the terms new documents start with: defaultTermsText (quotes), invoiceTermsText (blank prints the quote terms) and purchaseTermsText (blank prints nothing), payment instructions, the number formats for quotes, orders, invoices, purchases and payments, orderLeadTimeDays — the default lead time a new order's promised date starts on — and the packing-slip fields: packingSlipThankYou (Markdown with {{client.firstName}}, {{order.number}}, {{org.name}} and {{org.website}}), packingSlipShowPrices, packingSlipShowGiftMessage, packingSlipSize (A4/LETTER/LABEL_4X6), packingSlipSocialHandle and packingSlipReviewUrl), GET /settings/templates/designs (the fifteen designs and the two colour palettes the pickers offer, so you can discover a valid themeId rather than guessing one), GET/PUT /settings/sales (minimumMarginPercent — the gross-margin floor that flags an order on confirm; null clears it, and leaving it out of a save keeps it — defaultTaxGroupId, the tax a new line falls back to, pricesIncludeTax (prices are quoted with the tax already in them; each document keeps the mode it was raised under), blockNegativeStock — which makes being short of a material refuse a production run rather than warn about it — quoteFlow — whether an accepted quote becomes an order, an invoice, or a question each time — and the three autoEmailOnConfirm / autoEmailOnShip / autoEmailOnDeliver switches for the customer-facing order status emails) and GET/PUT/DELETE /settings/mail (your own SMTP server, or null while platform delivery is in use; the password is never returned, and signature and bccAll apply to every templated email).

GET/POST /suppressions and DELETE /suppressions/{id} are the addresses OrderDen has stopped emailing, because they bounced permanently, somebody reported the mail as spam, or they bounced temporarily three times inside 90 days with nothing getting through in between (SOFT_BOUNCE). Sending to one fails naming the address rather than disappearing into the provider. A single temporary bounce never lands here, and a successful delivery resets the count. Clearing one also clears it at the mail provider, whose own list is account-wide and would otherwise keep rejecting the address for a reason you cannot see. Saved SMTP settings only take over from OrderDen's own delivery once verified: POST /settings/mail/verify with { "to": … } sends a test email through them and marks them verified (verifiedAt).

GET/PUT /settings/payments reads and updates the connected payment account — accountId, onboardingComplete, chargesEnabled, payoutsEnabled, canAcceptPayments, and the acceptCards / acceptBankDebit / allowPartialOnlinePayment toggles. POST /settings/payments/connect returns a single-use hosted onboarding url to open in a browser (creating the account on first call); optional returnUrl / refreshUrl override where the processor sends the user back to. See Getting paid online.

Your data (full export)

GET /export streams a .zip of everything the workspace holds: CSV spreadsheets of every list, JSON of the complete records (lines, tax, shipments, payments, contacts, settings, the activity trail) and every uploaded file as it was uploaded. Secrets — SMTP passwords and API keys — are deliberately excluded. It is limited to one every 30 days; GET /export?check=1 reports { available, lastExportAt, nextAvailableAt } without building anything, and a 409 names the next available date.

Individual lists still export as CSV any time with ?format=csv. See Your data.

Worked example

BASE=https://your-domain.example/api/v1
AUTH="Authorization: Bearer $ORDERDEN_API_KEY"

# Create a client, quote them, accept, convert to an order
CLIENT_ID=$(curl -s -X POST $BASE/clients -H "$AUTH" -H "Content-Type: application/json" \
  -d '{"name": "Jane Doe", "companyName": "Acme"}' | jq -r .data.id)
QUOTE_ID=$(curl -s -X POST $BASE/quotes -H "$AUTH" -H "Content-Type: application/json" \
  -d "{\"clientId\": \"$CLIENT_ID\", \"billTo\": \"Acme, 1 Main St\", \"shipTo\": \"Acme, 1 Main St\", \"lines\": [{\"description\": \"Widget\", \"quantity\": 3, \"unitPrice\": 25}]}" | jq -r .data.id)
curl -s -X POST $BASE/quotes/$QUOTE_ID/status -H "$AUTH" -H "Content-Type: application/json" -d '{"status": "ACCEPTED"}' > /dev/null
ORDER_ID=$(curl -s -X POST $BASE/quotes/$QUOTE_ID/convert -H "$AUTH" | jq -r .data.id)

# Invoice it and record the payment
INVOICE=$(curl -s -X POST $BASE/orders/$ORDER_ID/invoice -H "$AUTH")
INVOICE_ID=$(echo "$INVOICE" | jq -r .data.id)
curl -s -X POST $BASE/invoices/$INVOICE_ID/payments -H "$AUTH" -H "Content-Type: application/json" \
  -d "{\"amount\": $(echo "$INVOICE" | jq -r .data.total), \"method\": \"card\"}"

For AI assistants

/llms.txt is a map of this API and the guides, in the format an assistant looks for before it starts guessing; /llms-full.txt is every endpoint and event in one file, for one with room to read it.

There is also an MCP server, so Claude, Cursor and anything else that speaks the protocol can work in your workspace directly:

{
  "mcpServers": {
    "orderden": {
      "command": "npx",
      "args": ["orderden-mcp"],
      "env": { "ORDERDEN_API_KEY": "od_live_…" }
    }
  }
}

It is an ordinary API client, so it gets the permissions of the key you give it, and the same per-minute rate limit. Give it a key made by an account whose access matches what you want it doing — a key that cannot see costs gives it an assistant that cannot see costs.