Bizom

Bizom is the sales force automation and distributor management system used by a large share of Indian FMCG and consumer brands to run their secondary and tertiary sales: the salesman app that takes an order at a kirana counter, the distributor system that invoices it, the stock and scheme rules behind it and the reporting on top. It is a product of Mobisy Technologies Pvt Ltd. For a unified commerce database it matters because it is the only place where a brand's general trade sales exist at all: no marketplace API will ever show you what a distributor sold to a retailer in Hubli. Bizom publishes no developer documentation, but unlike most platforms in this category it does run a real, reachable, token authenticated REST API at api.bizom.in, and enough of it can be confirmed from outside to plan an integration against. Everything below is either verified against that host on 2026-09-22 or explicitly marked as unpublished.

At a glance

What it is

Mobisy Technologies Pvt Ltd was founded in 2008 by Lalit Bhise, Shree Bhise and Vasudeva Manjunath, and launched Bizom, short for "Business on the Move", in 2012. Its own published figures are 750 or more brands, 250,000 or more sales force users, 8 million or more retailers covered and operations in 35 or more countries, with annual transaction value on the platform crossing one billion dollars as early as 2015. It raised seed funding from Ojas Ventures in 2012, a 3.5 million dollar Series A led by SIDBI Venture Capital in 2018 and a 12 million dollar Series B in 2024. The CIN it publishes is U72900KA2008PTC045157, which places the company in Karnataka.

The product is not a sales channel and not a marketplace. It is the software layer over general trade distribution: sales force automation, a web and mobile distributor management system, van sales, order management, retailer ordering, suggested and auto replenishment orders, trade promotion management, claims, merchandising, attendance, beat planning and a reporting layer marketed as Real Intelligence. It also sells a B2B commerce and WhatsApp ordering surface, and it registers brands as ONDC sellers.

Two things follow for the unified model. First, Bizom's "order" is usually a primary or secondary order, from brand to distributor or distributor to retailer, not a consumer order, so orders.channel should be set to a general trade value and never mixed with marketplace rows without a flag. Second, Bizom's retailer is a business, so customers here means outlets, not consumers, and the PII exposure is different in kind from a D2C channel.

Bizom Connect and the integration list

bizom.com/connect describes a two part tool: a "Connect Client" installed at the distributor to "integrate with standard distributor systems e.g. Tally, ERPs etc.", and a "Connect Backend" to configure each distributor's client and monitor sync across the downstream network. That is an agent based file or database bridge, not an API, and it is aimed at the distributor's accounting package rather than at the brand's data platform.

The published integration catalogue at bizom.com/integration covers Power BI and Snowflake for analytics, Microsoft Dynamics 365 and SAP ERP, Odoo, Syspro and Marg for ERP, BUSY and Tally Prime for accounting, E-Invoice and GST e-way bill for compliance, Darwinbox, greytHR, Oracle HRMS and Zoho People for HR, Kennect for incentives, and Accion, Mastercard and Loyltworks on the payments and loyalty side. The Snowflake entry is the interesting one for us: it says Bizom will land ERP, sales, marketing and distribution data in a warehouse, which is a supported bulk route that may be easier to negotiate than API access.

API access

There is no developer console, no application registration and no published key issuance. The route is commercial: you are a Bizom customer, or you are integrating on behalf of one, and Mobisy enables the API for that tenant. bizom.com/integration-request/ is the public form for asking.

Three environments were observed on 2026-09-22, each answering with the same bearer challenge:

There is also an ONDC gateway. Bizom operates as a Seller Network Participant on ONDC with bpp_id and bpp_uri of devapigateway.bizom.in/ondc in the preprod logs, on ONDC core version 1.2.0 across domains ONDC:RET10, RET13, RET16 and RET18. apigateway.bizom.in answers HTTP 404 in production, so the equivalent live host exists but its path layout is not public. If the requirement is to read a brand's ONDC orders, the ONDC protocol is a better documented route than Bizom's own API.

No SDK exists in any language. A GitHub search found no Mobisy or Bizom client library. A Postman public search found one user published workspace, not an official one.

Response format

Two conventions appear, and both are live. Some endpoints take the format as the last path segment, as in /oauth/directLogin/xml and /oauth/directLogin/json. Others take it as a query parameter, and the parameter name is inconsistent: responseType=json on the orders endpoint and responsetype=json on the sales endpoint. Assume parameter names are case sensitive per endpoint and copy them exactly.

Authentication

The flow is a direct credential exchange, not an OAuth redirect, despite living under an /oauth path. Verified against production on 2026-09-22.

1. POST the tenant's Bizom username and password to https://api.bizom.in/oauth/directLogin/xml or .../json.
2. The response carries a token. Calling the endpoint with no credentials returns the empty shape, which is how the field names below are known: XML gives <Response><Result>0</Result><Reason>Please provide username/ password</Reason><Token/></Response> and JSON gives {"Result":false,"Reason":"Please provide username/ password","Token":""}.
3. Pass the token on every subsequent call. Both styles work on the observed endpoints: an access_token=<token> query parameter, which is what the Postman requests use, or an Authorization: Bearer <token> header, which is what the WWW-Authenticate challenge asks for. Prefer the header, because a token in a query string ends up in access logs and in shared collections, which is exactly how the tokens in that public workspace leaked.
4. An unauthenticated call to a real endpoint returns HTTP 401 with body {"error":"invalid_request","error_description":"The access token was not found."}. An unknown path returns HTTP 404 with an HTML page titled "Bizom OAuth Login". That difference is a reliable way to tell a real endpoint from a guessed one.

Token lifetime, refresh mechanism, scopes and roles are not published. The token is tied to a user account, so the practical effect is that the API sees whatever that user sees in the application, and multi brand or multi distributor access is a matter of which account you were given rather than a scope parameter. Get the expiry behaviour in writing before building a refresh job, because a direct login flow with no documented refresh usually means you re-login when a call returns 401.

  obtain a token, JSON variant
curl -sS -X POST "https://api.bizom.in/oauth/directLogin/json" \
  -d "username=$BIZOM_USER" \
  -d "password=$BIZOM_PASS"

  an authenticated read, header style
curl -sS "https://api.bizom.in/orders/listordersapi?fromdate=2026-09-01&todate=2026-09-01&startseq=0&endseq=299&dateType=modified&getPrimaryOrders=1&responseType=json" \
  -H "Authorization: Bearer $BIZOM_TOKEN"

Objects we can read

Two endpoints are confirmed live in production. The rest of this section is honest about what could not be established. Sample responses are not published anywhere and the public Postman collection body is not retrievable, so no field level JSON can be given without inventing it.

Orders

GET /orders/listordersapi

Confirmed live in production (HTTP 401 unauthenticated, rather than the 404 login page). Parameters observed in real requests:

Pagination is an explicit index range rather than a cursor or a page number: you ask for records startseq to endseq within the date window. That means the window must be stable while you page it, so pin fromdate and todate and walk the range, rather than paging an open ended query. The sales endpoint uses a window of 300 records in the observed request, so 300 is a reasonable page size to assume until Mobisy says otherwise.

Sample response not published.

Order items

No separate endpoint was found. Line items are presumably nested in the order response, which is the usual shape for this kind of API, but that is inference. Sample response not published.

Products and listings

No endpoint confirmed. Guessed paths /skus/listskus and /masters/getskus both returned the 404 login page, which means those names are wrong, not that the capability is absent. Bizom certainly holds a SKU master with schemes and price lists, since the salesman app depends on it. Ask Mobisy for the master data endpoints by name.

Inventory

One inventory endpoint is visible in the public Postman workspace, GET /inventories/getwarehouseintransitinventories/{id}?skuStatus=1, but only against a per developer instance host, devhiremath.bizomdev.in. The same path returns the 404 login page on production, so either it was never released, it was renamed, or production mounts it elsewhere. Treat it as a hint about naming conventions, resource plural plus verb plus a path id, not as a usable endpoint. Distributor and retailer stock is core Bizom functionality, so an endpoint exists under some name. Sample response not published.

Shipments and tracking

Not applicable in the marketplace sense. Bizom tracks van sales and delivery against invoices rather than parcel waybills, and no endpoint was confirmed. For ONDC orders the fulfilment state arrives through ONDC on_status callbacks, with the states seen in the ONDC logs being agent assigned, picked up, out for delivery and delivered.

Returns and cancellations

No endpoint confirmed. General trade returns exist in the product as claims and damaged stock returns. The ONDC logs include an update_return action for the ONDC path. Sample response not published.

Payments and settlements

GET /payments/getsales

Confirmed live in production. Observed parameters:

The Postman request that carries these parameters is named "E-Invoice Get Sales", which together with invoiceStatus says this is the invoice level sales feed used for GST e-invoicing, not a payments or settlement ledger. In unified terms it is closer to orders plus tax detail than to settlements. Sample response not published.

Customers

Retailers and distributors, called outlets in the product. No endpoint confirmed. /outlets/listoutlets and /distributors/listdistributors returned the 404 login page. Any outlet data is business PII including owner name and phone number, and Bizom's own outlet deduplication feature implies the records are messy.

Locations

Warehouses appear in the inventory path fragment above. No confirmed endpoint.

Writing back: listings, price and stock

Bizom is not a sales channel, so there are no listings to update. The writes that would matter are order creation, stock updates and master data updates, and none could be confirmed from outside: /orders/createorder returns the 404 login page, and no POST endpoint other than the login was observed.

Three things are worth saying honestly. First, Bizom must accept order writes, because the retailer app, the WhatsApp ordering bot and the ONDC seller node all create orders in it. Second, the ONDC route is the one documented write path: a buyer application sends select, init and confirm to Bizom's ONDC gateway and Bizom answers with the on_ callbacks, all under the ONDC 1.2.0 specification, which is public. Third, for distributor side data the intended write mechanism is Bizom Connect's agent at the distributor rather than a call from your infrastructure.

If a brand wants stock or price pushed into Bizom from a central system, that is a contracted integration and the endpoint list has to come from Mobisy.

Webhooks and notifications

None published. No subscription endpoint, no signing secret and no retry policy was found.

For ONDC participants the callbacks are the ONDC protocol's own, on_select, on_init, on_confirm, on_status, on_track and on_update, signed per the ONDC signing specification and sent to the buyer application's registered URI. That is a formal contract but it only covers ONDC transactions, which for most brands is a small slice of their general trade volume.

Without push, poll. Both confirmed endpoints support dateType=modified or datetype=modified, which is exactly what incremental polling needs. A sensible cadence is every 15 minutes with an overlapping window of one hour on modified date, paging 300 records at a time, plus a nightly full day re-read to catch late edits. Do not poll on order date, because distributor edits land on the modified timestamp and would be missed.

Rate limits and pagination

Not published. No quota headers appear on the 401 responses, which carry only date, content-type, www-authenticate, server: Bizom, strict-transport-security and x-xss-protection. Until Mobisy states a limit, treat the 300 record page seen in the sales request as the intended batch size, keep to a single concurrent request per tenant, and back off on any non 401 error.

Pagination on both confirmed endpoints is the startseq and endseq index range inside a fromdate to todate window. There is no next cursor and no total count in the parameters, so the termination condition has to be a short page. That makes concurrent paging unsafe if records can be inserted mid scan, which is another reason to page a closed date window rather than an open one.

Mapping to the unified model

Gaps and open questions

• No published reference exists, so the endpoint inventory here is a sample of two confirmed paths plus one development only path. Ask Mobisy for the full list rather than guessing: the 404 versus 401 test makes guessing cheap but slow, and a wrong guess proves nothing.
• Token lifetime and refresh are the biggest operational unknowns. A direct login endpoint with no documented refresh usually means re-authenticating on 401, which is workable but needs a lock so that parallel workers do not stampede the login.
• The parameter naming is inconsistent between endpoints, dateType against datetype and responseType against responsetype, which suggests these endpoints were written at different times by different people. Do not assume a shared convention anywhere else.
• Whether the Snowflake integration can be pointed at a warehouse we control, and what its schema and refresh cadence are, is unanswered and is probably the highest value question to ask, because it would sidestep the undocumented API entirely.
• Write access could not be established at all. Nothing here should be read as saying Bizom cannot accept writes.
• The relationship between the ONDC gateway and the main API is unclear. They are on different hosts and probably different services.
• The public Postman workspace contains what look like live staging and development tokens. Someone at Mobisy should be told.

Sources

• Live responses from https://api.bizom.in, probed 2026-09-22: the bearer challenge and server: Bizom header, HTTP 401 on /orders/listordersapi and /payments/getsales, HTTP 404 with the "Bizom OAuth Login" page on unknown paths, and the XML and JSON error bodies from /oauth/directLogin/xml and /oauth/directLogin/json.
• Live checks on stagingapi.bizomstaging.in, devapi.bizomdev.in and apigateway.bizom.in, 2026-09-22.
• Public Postman workspace "Bizom" and the associated public requests, indexed by Postman's own search API and read 2026-09-22: the request URLs that reveal the parameter sets for /orders/listordersapi, /payments/getsales, /oauth/directLogin/xml and /inventories/getwarehouseintransitinventories/{id}.
• ONDC-Official/v1.2.0-logs, the Bizom directory, read 2026-09-22: Bizom's bpp_id and bpp_uri of devapigateway.bizom.in/ondc, ONDC core version 1.2.0, domains RET10, RET13, RET16 and RET18, and the action set including on_status and update_return.
• bizom.com/about, read 2026-09-22: entity, founders, founding year, scale figures, funding, CIN.
• bizom.com/connect, read 2026-09-22: Connect Client and Connect Backend.
• bizom.com/integration, read 2026-09-22: the integration catalogue including Snowflake and Power BI.
• bizom.com/sitemap.xml and the page and integration sub sitemaps, read 2026-09-22: confirmation that no developer or API page is published.
• GitHub code search for "bizom.in" and "oauth/directLogin", 2026-09-22: no SDK or integration library.