Omnee Lab

Omneelab is an Indian enterprise supply chain execution platform, not a carrier and not a marketplace. It sells two products: Omneelab WMS, a warehouse management system that runs inside a company's four walls including in-plant logistics, and Metaport, a transportation control tower and last mile "bring your own courier" layer that sits over a brand's existing courier contracts. For a seller it matters as the system of record for inventory and dispatch, and as the place where courier performance and cost per delivery are measured. It publishes no API documentation, and its integration model is prebuilt connectors delivered by its own implementation team rather than a self serve API.

At a glance

What it is

Omneelab positions itself as an "AI supply chain execution platform, plant to door". The published claims, read from its own site on 2026-09-22, are 70 plus customers, 30,000 plus daily orders and 85 plus integrations, with named logos including Shell, Goodyear, Hindware, Lotto, Apollo Tyres, EDAC and Wonder Products. That customer profile is manufacturing and building products rather than D2C brands, which tells you the product is bought by operations and IT rather than by a growth team.

The two products divide cleanly:

• Omneelab WMS covers receiving, putaway, picking, dispatch, unit level stock down to zone, bin, SKU and unit, AI demand forecasting, in-plant material flow and BOM or kitting consumption. It is explicitly positioned to sit alongside an existing ERP rather than replace it, with two way sync to SAP, JD Edwards, Navision, Tally-ERP and CRMs, and to marketplaces including Amazon, Flipkart and Blinkit with single stock pool allocation.
• Metaport, marketed as Last Mile BYOC (bring your own courier), is a transportation control tower. The seller keeps its own courier contracts and Metaport adds allocation, a branded courier agnostic tracking page, unified tracking across carriers, cost per delivery analytics and courier performance comparison. Its own case figure is a reduction from Rs 85 to Rs 64 per delivery, and it claims 50 plus companies using it.

So there are two distinct integration questions here, and they have different answers: WMS integration is about inventory and orders, Metaport integration is about shipments and courier events.

API access

There is no developer programme, no API key console, no published reference and no self serve path. Every route that would normally hold one was checked on 2026-09-22: docs.omneelab.com and developer.omneelab.com do not resolve, omneelab.readme.io returns 404, api.omneelab.com and api.omneelab.in do not resolve, and the page sitemap at omneelab.com/page-sitemap.xml lists only twelve marketing pages with no developer or API entry among them.

What the vendor does say about integration, quoted from its WMS and last mile pages:

• "85+ stable API integrations with two-way sync. Omneelab WMS amplifies your existing stack, it doesn't replace it."
• "Connect marketplaces, couriers and your ERP via 85+ ready APIs. Standard courier integrations in 24 hours."
• "Don't see your platform? Custom integrations delivered in 3 to 5 days."
• Implementation is quoted at "as little as 2 weeks" with the vendor's own team.
• Metaport lists an "API Gateway" feature with the benefit "90% faster courier onboarding" and the mechanism "standardized integration for any courier", with a customer quote about adding two local couriers in 48 hours.

Read carefully, none of that is an offer of an open API. It is a catalogue of connectors that Omneelab builds and operates, plus an internal gateway that normalises carriers on the way in. The commercial model is that the vendor builds the integration for you within days, which is a reasonable offer but means there is nothing for an outside engineer to build against unaided.

The practical access route is therefore: request a demo, get to a contract, and ask the implementation team for the integration specification during onboarding. Ask specifically for the Metaport courier gateway specification if the goal is shipment and tracking data, since that is the interface described as standardised.

No SDK, Postman collection or OpenAPI specification is published in any language, and no GitHub repository referencing Omneelab's API exists. No API version is known to be in force and no deprecation policy is published.

Authentication

Not published. No credential type, no token endpoint, no header name, no lifetime, no scope model and no multi tenant mechanism is described in any public source. The application sign in page at app.omneelab.com/login is a conventional server rendered form (the page serves jQuery and SweetAlert2 and no application bundle), so there is no client side API base URL or route table to inspect.

Because a fabricated example would be worse than none, no token request or authenticated call sample is given here. The credential model has to come from the vendor.

The only inference worth recording for a credential store design: since this is an enterprise contract product with per customer implementation, expect one credential per customer tenant, probably issued out of band by the implementation team, and expect no application level delegation across customers.

Objects we can read

Nothing is readable from outside the platform, and no endpoint, parameter, pagination model or field name is published for any object. What follows is the object inventory that exists inside the product, taken from the vendor's own feature descriptions, so that an integration conversation can be scoped.

Inventory

The richest object in the product. Stock is tracked at zone, bin, SKU and unit level, held as a single pool and allocated out to all connected marketplaces "with zero time lag". Multi warehouse is native. This is the object most likely to be worth reading, and the one for which inventory.quantity_available, location_id and updated_at would map most naturally. Endpoint and schema not published.

Orders and order items

Orders arrive from connected channels (Amazon, Flipkart, D2C storefronts, Blinkit and other quick commerce) and from ERP systems, and are fulfilled through picking and dispatch. Mixed receiving and shipping is supported, described as receiving cartons and shipping single pieces for D2C and marketplace orders. No read endpoint is published.

Shipments and tracking

This is Metaport's territory. Unified tracking across whichever couriers the brand uses, a branded tracking page in place of the carrier's own, and courier performance and cost analytics per region. Since Metaport normalises many carriers behind one gateway, a normalised shipment and event schema must exist internally, which would be the single most valuable thing to obtain. Nothing about it is published: no status vocabulary, no event shape, no NDR or RTO handling, no proof of delivery artefact, no COD remittance.

Products, listings, returns, payments and settlements, customers, locations

Products and locations clearly exist as master data, since the WMS is organised around SKUs and bins. Returns, settlements and customers are not described as product areas at all. No endpoint is published for any of them.

Sample responses are not published for any object.

Writing back: listings, price and stock

Not applicable, this is a logistics tool rather than a carrier or a sales channel, so neither the carrier framing nor the listings framing fits exactly. Two things are worth being precise about:

• Stock does flow outward. Omneelab synchronises its single stock pool to connected marketplaces, which means stock levels on Amazon, Flipkart and quick commerce channels can be driven from Omneelab. That is a platform feature performed by Omneelab's own connectors, not an API surface a third party can call, and it is the opposite direction from what a unified database usually wants.
• Price and listing content are not in scope. Nothing in the product description covers listing creation, price changes, MRP, listing status or listing content. There is no evidence of any catalogue authoring capability.

On the shipment side, the write operations that must exist internally are dispatch creation, courier allocation and label or manifest production, since the WMS dispatches and Metaport allocates. No endpoint, request body, batch size or confirmation mechanism is published for any of them.

Webhooks and notifications

Not published. The vendor uses the words "two-way sync" and "real-time" repeatedly, and a control tower that reports live courier status necessarily consumes carrier webhooks on the inside, but there is no public event catalogue, no subscription or registration endpoint, no signing secret or signature header, and no retry policy.

With no API and no webhook contract, there is nothing to poll either. For a unified database the realistic options are, in order of preference:

1. Ask during onboarding for a push feed (webhook or message queue) of inventory changes and shipment events, and for the normalised schema behind Metaport's carrier gateway.
2. Failing that, ask for a scheduled file export (SFTP or object storage drop) of inventory snapshots and shipment event deltas. Enterprise WMS vendors almost always have this even when they have no public API, and it is the pattern to ask for by name.
3. As a last resort, read the same data from the channels and carriers directly and use Omneelab only as the operational system, accepting that the unit level bin data will not be available.

Rate limits and pagination

Nothing is published: no limits, no quota headers, no pagination model, no list endpoints, no date window queries and no bulk or backfill route. There is no basis for a sync cadence recommendation until the vendor supplies a specification. If a file export is agreed instead, the practical design is a daily full inventory snapshot plus an hourly event delta, which is what this class of product usually supports.

Mapping to the unified model

Only the object level intent can be stated. No field names are published, so every platform field is recorded as unpublished rather than guessed.

Gaps and open questions

• No technical source of any kind exists publicly. This page is built from marketing copy and negative probes, which is why confidence is low.
• It is not established whether Omneelab offers an inbound API to customers at all, or only outbound connectors that its own team builds. The phrasing "85+ ready APIs" and "custom integrations delivered in 3 to 5 days" reads as the latter.
• Authentication, rate limits, pagination, error handling and versioning are all entirely unknown.
• Whether a file export route exists (SFTP, object storage) is unknown and is the first thing to ask, since it is the likeliest route to bulk data for this class of vendor.
• The Metaport carrier gateway's normalised shipment and event schema is the single most valuable unknown. If it can be obtained, it would cover shipments for whatever carriers the customer uses.
• Whether inventory can be read at unit level through any interface, or only viewed in the application, is unknown.
• No pricing is published for the platform or for custom integration work.
• Recommend this entry be treated as an enterprise integration to be scoped in a call, not a connector that can be built from documentation. Correct the display name to "Omneelab" and note the two product halves separately, since WMS and Metaport are different integrations.

Sources

• Omneelab homepage for the platform positioning, the two product split, and the 70 plus customers, 30,000 plus daily orders and 85 plus integrations claims
• Omneelab WMS product page for the integration claims, the marketplace and ERP connector lists, unit level stock granularity and the implementation timelines
• Omneelab Last Mile BYOC / Metaport page for the API Gateway feature, courier agnostic tracking, the 50 plus companies figure and the cost per delivery claim
• Live probes on 2026-09-22: docs.omneelab.com, developer.omneelab.com, api.omneelab.com and api.omneelab.in do not resolve, omneelab.readme.io returns 404, app.omneelab.com redirects to a server rendered /login form, and omneelab.com/page-sitemap.xml lists no developer or API page