Till King Gateway API

Registers (or re-registers) a device with the gateway. No prior auth required. Re-registering the same device_id updates the existing record and issues a fresh token.

{
  "device_id": "unique-device-uuid",
  "device_name": "Till 1 Front",
  "tenant_subdomain": "shop1",
  "branch_id": null
}

201 → { token, expires_at, tenant_name, device_id }

Normalises the client POS payload to ERPNext Sales Invoice format and forwards to the tenant’s ERPNext instance. Items, payments, and customer are mapped using the tenant’s config rules.

{
  "items": [
    { "item_code": "POSHO-5KG", "item_name": "Posho 5kg", "qty": 2, "rate": 24000 }
  ],
  "payments": [
    { "method": "cash", "amount": 30000 },
    { "method": "momo", "amount": 18000, "reference": "MTN-077..." }
  ],
  "customer": "Walk-in Customer",
  "branch_id": 1,
  "till_id": "TILL-01"
}

201 → { invoice_id, total, net_total, items, payments }

Accepts up to 500 transactions per batch. Jobs are enqueued to Redis and processed by background workers with exponential backoff on failure.

{
  "transactions": [
    { "type": "sale", "payload": { ... } },
    { "type": "return", "payload": { ... } }
  ]
}

202 → { batch_uuid, job_count, enqueued, redis_ok }

Returns the batch status and per-job statuses. Jobs cycle through pending → retrying → synced (or failed after 5 attempts).

200 → { batch_uuid, status, summary, jobs[] }

Proxies any request to the tenant’s ERPNext API. The tenant is resolved from the Host header (subdomain). The gateway attaches the tenant’s API credentials automatically — the client never sees them.

Example: GET testshop.tillking.com/erpnext/Sales%20Invoice?fields=["name"]