QueueBuster

QueueBuster publishes a full partner API at docs.queuebuster.co. Client credentials return a 24 hour token; sales, stock, catalogue and customers are readable.

QueueBuster is an Android point of sale from MapleGraph Solutions Pvt. Ltd., founded in 2016 and based in Noida. It sits at the till in everything from single kiosks to large format retail chains, covering billing, inventory, a digital ledger, an online storefront, customers and loyalty. The vendor's own figures, read on 2026-09-22, are around 86,000 merchants, over 4 million invoices a month, more than four countries and over 50 integrations.

For a connector, QueueBuster is the best documented product in this part of the catalogue. It publishes a complete partner API reference at docs.queuebuster.co, a Postman-hosted documentation set on the vendor's own domain, covering general setup, catalogue, the QB eStore online channel, reports and analytics, customers, purchasing, inventory and webhooks. Store sales, stock movements, customers and the catalogue are all readable, and stock and per-store price can be pushed back.

At a glance

Warning

The collection's own overview says "All the APIs are secured by Oauth 2 encryption". That is not what the documented requests do. There is no OAuth authorisation flow, no scopes, no refresh token and no Bearer prefix. What exists is a client id and client secret posted to a token endpoint, returning an opaque token valid for 24 hours, sent as the bare value of an Authorization header. Build to the documented requests, not to the overview sentence.

What it is

QueueBuster describes itself as "India's leading business super app" and "a powerful Android-based Mobile POS application for all kinds of businesses. From large format retail stores to small carts and kiosks". The feature set named by the vendor is billing, inventory, Khata (a digital ledger), Online Dukaan (a storefront), customers and loyalty. Merchant logos on the site include Heineken, HUL and ITC, so the customer base spans small retail through to enterprise brand estates.

The data model has three nesting levels that every request repeats, and getting them right is most of the integration work:

Chain. The merchant's business, identified by chainID or chain_id. A chain must be explicitly authorised to share data with a given partner.
Third party chain. The partner's view of that chain, identified by thirdPartyChainID or third_party_chain_id. This is the mapping between your integration and the merchant, and it is what makes the API multi-tenant.
Store. A physical or online outlet under the chain, identified by storeID or store_id, with shortCode and storeCode alongside.

Below that sit products, variants (called batch variants in places), units, categories, sub-categories, brands, taxes and charges.

API access

There is no self-serve developer signup. Access requires:

A partner agreement with QueueBuster, producing a clientID and clientSecret.
The merchant's chain being mapped to your third party id. The documentation for the stock transaction endpoint states the prerequisite directly: "Chain should be authorized to share data with third party clients (chainID should be mapped to thirdparty ID)".
Some endpoints have further merchant-side settings. The same page notes that attribute mapping requires the "Automate Product Group Creation" setting to be enabled.

Environments visible in the documentation:

The common prefix is /API/public/v1/. No OpenAPI specification, no SDK and no versioning beyond v1 in the path.

Note

A real trap in this API: path casing is inconsistent and so is field naming. Some endpoints sit under /thirdparty/ and others under /thirdParty/, sometimes for neighbouring operations in the same folder. Request bodies mix camel case (thirdPartyChainID, chainID, storeID) with snake case (third_party_chain_id, chain_id, store_id), and the choice tracks the endpoint, not the module. Copy each path and each field name exactly from the documentation for that operation. Do not normalise.

Authentication

Client credentials for a 24 hour token.

Request:

POST /API/public/v1/partner/generateToken HTTP/1.1
Host: api.queuebuster.co
Content-Type: application/json

{
  "clientID": "YOUR_CLIENT_ID",
  "clientSecret": "YOUR_CLIENT_SECRET"
}

Response:

{
  "status": true,
  "token": "ca379f357b92a8846663dfa500224be7328ecba5f2ffe727a23c0bce5c3e67c1",
  "issued_at": "2023-01-18 14:25:15",
  "expires": "2023-01-19 14:25:15"
}

The vendor describes the token's purpose as fetching "the catalogue and store related information for a chain hosted by QB", and adds that it "can also be used to receive external online orders as well as for sharing invoice information with the partner". One token covers reads, order injection and invoice sharing.

Authenticated call:

POST /API/public/v1/thirdParty/fetchStoreSalesInvoice HTTP/1.1
Host: api.queuebuster.co
Authorization: ca379f357b92a8846663dfa500224be7328ecba5f2ffe727a23c0bce5c3e67c1
Content-Type: application/json

{
  "third_party_chain_id": 50,
  "chain_id": 1534,
  "store_id": 2453,
  "sales_date": "2022-09-30"
}

Notes for the credential store:

The token is a 64 character hex string, sent as the entire header value. No Bearer, no Token, no prefix.
Lifetime is exactly 24 hours, stated as an absolute expires timestamp rather than a duration. Refresh on a timer keyed to expires, with a re-issue on any authentication failure.
The token is per partner, not per merchant. Tenancy is expressed in the request body through the chain and third party chain identifiers, not in the credential. One token, many merchants.
Timestamps in the token response carry no timezone. The stock transaction endpoint takes an explicit timezone field with Asia/Kolkata as the example, so treat all bare timestamps as merchant-local and store the zone separately.

Objects we can read

Every read is a POST with a JSON body. Responses share a loose envelope: status as a boolean, usually data as an array, often count, sometimes message, and on several endpoints an apiTrackerID which is a per-partner usage trace value worth logging.

Orders and invoices

POST /API/public/v1/thirdParty/fetchStoreSalesInvoice returns the bills for one store on one day. Mandatory fields are third_party_chain_id, chain_id, store_id and sales_date. This is the core sales read.

{
  "status": true,
  "data": [
    {
      "customer": {
        "name": " ",
        "email": "",
        "phone": "",
        "address": {
          "line_1": "", "line_2": "", "city": "", "pin": "",
          "landmark": "", "sub_locality": null, "tag": "",
          "latitude": 0, "longitude": 0, "is_guest_mode": false
        }
      },
      "chainID": 597,
      "store_id": 847,
      "billing_user": "Snehafarm",
      "details": {
        "order_id": "OR422620210818-1",
        "invoice_number": 1,
        "device_id": 4226,
        "instructions": "",
        "item_level_total_charges": 0,
        "item_level_total_taxes": 0,
        "order_level_total_charges": 0,
        "order_level_total_taxes": 0,
        "order_subtotal": 748.98,
        "order_total": 749,
        "payable_amount": 748.98,
        "total_charges": 0,
        "total_taxes": 0,
        "order_date": "2021-08-18",
        "order_time": "2021-08-18 12:50:31",
        "items": [
          {
            "product_id": 7,
            "title": "Chunky Sriracha Prawn Spread",
            "sku": "",
            "barcode": "",
            "hsn_code": "",
            "brand": "none",
            "category": "none",
            "sub_category": "",
            "unit": "Piece",
            "quantity": 1,
            "price": 249,
            "total": 249,
            "total_with_tax": 249,
            "discount_total": 0,
            "discounts": [],
            "taxes": [],
            "charges": [{ "id": 50, "title": "Delivery Charge", "rate": 50 }]
          }
        ],
        "payment": [
          { "payment_subid": 1, "payment_type": "PAYMENT_CASH", "amount": 749 }
        ]
      }
    }
  ]
}

The customer block is PII. device_id identifies the till that raised the bill, which is useful for reconciliation and for spotting a misconfigured device.

Order items

Inside details.items, as shown above: product_id, title, sku, barcode, hsn_code, brand, category, sub_category, unit, quantity, price, total, total_with_tax, discount_total, and arrays for discounts, taxes and charges. Taxes and charges are arrays of objects with id, title and rate, at both item and order level.

Products and listings

POST /API/public/v1/thirdparty/{chainID}/fetchProducts takes a page field and returns count plus a product array: productID, productName, categoryName, subCategoryName, brandName, soldInUnit, soldIn, HSNOrSACCode, variantIDs, variantNames. Note that the chain id is in the path here, not the body.
POST /API/public/v1/thirdparty/{chainID}/fetchProductByBarCode and .../fetchProductBySku for single lookups.
POST /API/public/v1/thirdparty/fetchStoreCatalogue, fetchStoreCatalogueBySku and fetchStoreCatalogueByBarcode for what a specific store actually sells and at what price. This is the listing-equivalent object: a product becomes sellable at a store through the store catalogue.
fetchWareCatalogueBySku and fetchWareCatalogueByBarcode for warehouse catalogues.
fetchBatchVariants and fetchStoreBatchVariants for variants.
Categories, sub-categories, brands, measurement units, chain taxes and chain charges each have a fetch endpoint.
Custom price lists: getPriceListSummary, getPriceListDetail, getPriceListChannels, getPriceListCustomers.

Inventory

POST /API/public/v1/thirdparty/fetchStockTransactions and fetchStockTransactionDetail.
POST /API/public/v1/thirdparty/storeStockTransactionTracker takes thirdPartyChainID, chainID, sourceType, sourceID, fromDate, toDate and transactionType, and returns movements with transactionID, transactionType (for example Stock In), sourceID, sourceName, destinationID, destinationType, status (for example APPROVED), transactionDate, transactionTime, transactionTimeLocal, totalCost, freightCharge, invoiceNumber, invoiceDate, totalItemNumber, userName, vendorName, remarks and a nested transactionProducts array.
listOfStockRequisition and fetchStockRequisitionDetails for requisitions.

Note what this is: a movement ledger, not a balance. There is no documented "current stock by SKU and store" endpoint. A balance has to be derived from the store catalogue plus the movement history, or obtained another way. Confirm with QueueBuster whether a balance endpoint exists outside the published collection.

Returns

Refunds arrive through the receiveRefundInvoice webhook. On the purchasing side, fetchPurchaseReturns and fetchPurchaseReturnDetails cover vendor returns.

Payments and settlements

Payments are on the bill, as the payment array with payment_subid, payment_type (for example PAYMENT_CASH) and amount. The booking-oriented variant of the API also documents PAYMENT_PARTY with a partyID and partyName, used for online debtor settlement against a payment gateway. Vendor settlement has getVendorBills, getVendorBillDetail and vendorBillSettlement. There is no marketplace settlement object.

Customers

POST /API/public/v1/thirdParty/getCustomerList returns customerID, customerType (for example INDIVIDUAL), firstName, lastName, phone, email, gender, addressLine1, addressLine2, city and more. All PII.
fetchCustomerDetailByPhone for a single lookup, fetchCustomerOrders for their history, fetchCustomerCreditNotes for credit notes.

Locations

POST /API/public/v1/thirdparty/getChainStoreList takes chainID and thirdPartyChainID and returns chainID, storeID, brandName, storeName, shortCode, storeAddress, storeType, storeCode. getThirdPartyStores returns the stores visible to a partner. getAllOnlineStores covers the QB eStore side. This is the first call any connector should make.

Shipments

No shipment object and no carrier data. QueueBuster is a till, not a logistics system.

Writing back: listings, price and stock

All three are writable, which puts QueueBuster well ahead of the other Indian POS entries in this catalogue.

Stock

POST /API/public/v1/thirdparty/stockTransaction posts a movement:

{
  "thirdPartyChainID": 63,
  "chainID": 1424,
  "timezone": "Asia/Kolkata",
  "transactionTimeLocal": "2024-03-13 00:00:00",
  "sourceID": 2283,
  "sourceType": "STORE",
  "destinationID": 4092,
  "destinationType": "STORE",
  "transactionType": "STOCK_IN",
  "invoiceNumber": 5000000752,
  "invoiceDate": "2024-03-13",
  "vendorID": "1",
  "remarks": "ok",
  "userID": 2020,
  "transactionProducts": [
    {
      "productID": "40",
      "productName": "Contempo Square Mirror",
      "variantID": "19191",
      "variantName": "8907895081805",
      "unitID": "DEFAULT",
      "unitName": "Piece",
      "quantity": 5,
      "costPrice": "2",
      "MRP": 100,
      "barcode": "8907895081811",
      "sku": "000000061000151"
    }
  ]
}

Response:

{
  "status": true,
  "transactionID": 230,
  "message": "Stock transaction successfully done!"
}

Source and destination are typed (STORE here), so transfers between stores and between warehouse and store use the same call. Stock is moved, never set to an absolute figure.

Price and per-store listing

POST /API/public/v1/thirdparty/{chainID}/manageStoreCatalogue assigns products to a store with a price:

{
  "storeID": "3864",
  "productList": [
    { "productID": 1, "variantID": 1, "price": 1010 },
    { "productID": 11, "variantID": 11, "price": 1100 }
  ]
}

assignStoresCatalogue does the bulk assignment across stores. Price lists have their own create, update and delete endpoints, with channel and customer scoping, which is how a retailer sets different prices by channel or by customer group.

Catalogue

addProductsBulk, updateProductsBulk and deleteProductsBulk, with matching bulk endpoints for categories, sub-categories and brands, plus create and update for gift voucher products, inventory attributes and batch variants.

Orders

POST /API/public/v1/thirdParty/externalEcomOrder injects an order raised outside QueueBuster into the merchant's books. It takes a customer block with a full address, external_order_id, chain_id, third_party_chain_id, store_id, billing_user and a details block mirroring the sales invoice structure.

{
  "status": true,
  "message": "Order successfully recorded",
  "order_number": "PI-OL-598-848-74",
  "apiTrackerID": "API-35-042021"
}

external_order_id is the external reference, and is the natural idempotency key, though the documentation does not state that duplicates are rejected. Test it. Related e-commerce endpoints cover customerOrderListing, thirdPartyCustomerOrderDetail, customerInvoiceSettlement and addCustomerMoney.

Purchasing and administration

Purchase orders have create, update, fetch, fetch with details, approval status update and a Tally-oriented fetch. Vendor bills have create and settle. Vendors can be added, edited and mapped to sources and products. Users, roles, stores and channels can all be created and edited through the API, which means a partner can provision a merchant end to end.

Webhooks and notifications

QueueBuster pushes to a partner endpoint. Five events are documented, each with a full example body:

The sales invoice body is the same shape as the fetchStoreSalesInvoice response element: a customer block, chainID, store_id, billing_user and a details block with order_id, invoice_number, device_id, item and order level charges and taxes, order_subtotal, order_total, payable_amount, items and payment. It adds panNumber to the customer block, which the fetch response does not show.

Verification is the weak point. The documented examples authenticate with a static shared secret string in an Authorization header. There is no HMAC signature, no timestamp and no replay protection documented. If you consume these, treat the secret as a bearer credential: terminate on HTTPS only, compare in constant time, rotate it, and additionally verify each invoice by reading it back through fetchStoreSalesInvoice before treating it as final. Ask QueueBuster whether a signing scheme exists that is not in the public collection.

No retry policy, delivery guarantee or ordering guarantee is documented. Assume at-least-once at best, and deduplicate on order_id plus store_id.

With webhooks available for sales, refunds and stock, the sensible design is webhook-driven with a daily reconciliation pass over fetchDayWiseStoreStatistics per store to catch gaps, falling back to chainSalesTransactionTracker for any date where the counts disagree.

Rate limits and pagination

No rate limit, quota header or concurrency guidance is published anywhere in the collection.

Pagination is thin and inconsistent. fetchProducts takes a page field and returns count, but no page size, no total pages and no cursor. Most other list endpoints take no pagination at all and return everything matching the filter, which for a large chain's customer list or a busy store's daily bills could be a very large response.

The apiTrackerID returned by several endpoints, in the shape API-{thirdPartyChainID}-{MMYYYY}, looks like a per-partner per-month usage trace. That is consistent with usage being metered somewhere even if no limit is published. Log it.

Practical cadence: webhook-driven for sales and stock, a nightly pass for statistics and a weekly full catalogue refresh, with a single request in flight per merchant until QueueBuster gives you numbers.

Mapping to the unified model

Gaps and open questions

The overview's OAuth 2 claim contradicts every documented request. Confirm which is authoritative, and whether a real OAuth flow exists for some partner tier.
No current stock balance endpoint is published. Only movements. This is the largest functional gap.
Webhook verification is a static shared secret with no signature and no timestamp. Ask for a signing scheme.
No rate limit, no quota header, no concurrency guidance, and no documented page size on the one endpoint that paginates.
No changed-since filter on sales. Incremental sync is a loop over dates, and edits to a closed day will be missed.
Line items have no identifier, which makes exact line-level reconciliation across syncs fragile.
Field naming and path casing are inconsistent between endpoints. There is no way to infer the correct form; it must be copied per endpoint.
Several documented examples point at beta., staging., testapi. or even localhost. The production host and path for each operation must be confirmed, not assumed from the example.
One documented example response for fetchStoreCatalogue is a server error page rather than JSON, which suggests the collection is not fully maintained. Treat sample responses as indicative.
Whether external_order_id is enforced as unique, and therefore usable for idempotency, is not stated.
Onboarding terms, cost and time to get a client id and secret are not published.
There is a second, separate QueueBuster collection in public Postman oriented at bookings and ticketing, using /v1/thirdparty/generateSalesOrder, fetchSalesOrderDetail and updateSalesOrder with visitDate and customer group pricing. It appears to be a vertical variant for attractions and events. If a merchant is in that vertical, ask QueueBuster which surface applies.

Sources

QueueBuster QB Integration API collection, read 2026-09-22. The vendor's published documentation, served through Postman on the vendor's own domain. Source of every endpoint, request body, sample response, header and token behaviour on this page. Folders: General, Catalogue, QB eStore, Reports and Analytics, Customer, Purchase, Inventory, Webhooks
QueueBuster home page and about page, read 2026-09-22. Founded 2016, MapleGraph Solutions Pvt. Ltd., Android POS, around 86,000 merchants, over 4 million monthly invoices, four or more countries, over 50 integrations
Public Postman collection "Queuebuster", uid 41639431-3a48cd67-fb51-4e2c-8365-2c96417dc1a4, retrieved 2026-09-22. A separate booking and ticketing oriented surface under /v1/thirdparty/
DNS and certificate transparency checks on 2026-09-22: api.queuebuster.co fronts an AWS load balancer in ap-south-1; docs.queuebuster.co is a CNAME to Postman's documentation host; staging, beta, test, shop, ebill, staffhub and networkpos subdomains exist
GitHub repository and code search for queuebuster, run 2026-09-22: no vendor owned repository or SDK. Matches are an unrelated LinuxCNC feature of the same name