Order Talk

ERP Integration & Order Dispatch

Four ways an order reaches the system that fulfils it — Priority ERP, any REST endpoint, HMAC-signed webhooks and flat-file CSV — with a per-tenant callback so the ERP can report back.

Dispatch

Four ways out, because ERPs differ.

An ordering front end is only worth anything if the order reaches the system that fulfils it. There is direct submission to Priority ERP, submission to any REST endpoint a customer nominates, HMAC-signed webhook delivery for receivers that want to verify origin, and flat-file CSV export for the systems that will only ever accept a file. A per-tenant callback endpoint lets the ERP report back on what it did.

Priority ERP

Direct submission to Priority.

🔗

REST endpoint

Any endpoint the customer nominates, configured per tenant.

🔏

Signed webhook

HMAC-signed, so the receiver can verify the order really came from here.

📄

Flat-file CSV

For the systems that will only ever accept a file, and there are always some.

The boundary

It feeds the ERP. It is not the ERP.

OrderTalk owns the conversation, the catalog matching, the approval of who may order and the reliable delivery of the resulting order. Stock, pricing authority, fulfilment, invoicing and the rest stay in the system that already does them. The integration surface exists so that boundary can be clean rather than blurred.

The full reference

Every surface, by group.

💬 Where the order comes in

WhatsApp channel

  • WhatsApp webhook — The per-tenant inbound endpoint. A distributor’s message arrives here and becomes an order candidate.
  • Chat & chat API — A web chat surface running the same parsing and matching as WhatsApp — useful for demos, and for anyone who would rather type in a browser.
  • WhatsApp admin — Connection state for the channel, including the pairing QR and a live status endpoint, so an administrator can see whether the number is actually connected.
👤 Self-service, for the approved

Distributor

  • Registration — A public per-tenant registration page. Submitting it creates a request, not an account.
  • Portal orders — List, place and inspect orders from the browser, for distributors who want a record rather than a chat scroll.
  • Product list & search — The tenant’s catalog, with the same fuzzy search the chat engine uses.
  • Distributor login — A separate authentication path from the administrative one.
Running it

Administration

  • Dashboard — The live operating view — what is coming in and what needs attention.
  • Orders — The order list and the detail behind each one, including its dispatch state.
  • ERP failures — What failed to reach the ERP, per order, so a dispatch problem is visible rather than silent.
  • Registrations — The approval queue — approve or reject each requesting phone number.
  • Phone approvals — The same queue at tenant scope, for operators managing several businesses.
  • Tenants — Create and inspect tenants, and the per-tenant configuration behind each.
  • Admin login — Administrative authentication, distinct from distributor sign-in.
📦 What can be ordered

Catalog

  • Catalog list & editor — Products with SKUs, pricing and categories, editable in the admin UI.
  • Bulk import — Import a catalog via CSV or JSON rather than entering it by hand.
  • Upsert & deactivate — Programmatic product maintenance, per tenant, over the API.
Where the order goes

Integration

  • Priority ERP — Direct submission to Priority.
  • REST endpoint — Submission to any REST endpoint the customer nominates.
  • Signed webhook — HMAC-signed delivery, so the receiving system can verify the order actually came from here.
  • Flat-file export — CSV, for the systems that will only ever accept a file.
  • ERP callback — A per-tenant callback endpoint so the ERP can report back on what it did with the order.
Under it

Platform & architecture.