Shipsy

Shipsy is an enterprise logistics software platform, not a carrier. It sells a transportation management system, a warehouse management system, multi-carrier management, route optimisation and international freight and container tracking to logistics providers, retailers, post and parcel carriers and freight forwarders. For a brand, Shipsy is the layer that decides which carrier gets an order and where the shipment is, so its data model is where shipments, locations and carrier status mappings live. Its API is real and heavily used, but it is an enterprise contract product: there is no public developer portal and no self-serve credential.

At a glance

What it is

Shipsy (Gurugram, India, with offices across the Middle East and South East Asia) sells an AI oriented logistics operating platform. Its own site states it was recognised in the 2026 Gartner Magic Quadrant for Transportation Management Systems as a Niche Player for a third consecutive year, and named a Representative Vendor in the 2026 Gartner Market Guide for Multicarrier Parcel Management Solutions.

The product is modular. The public knowledge base lists 22 modules and 315 articles: Core Platform (masters, hubs, users, configuration), Multi-Carrier Management, Integration Marketplace, Communication Engine, Business Booking Engine, Hub Operations and Mid Mile, Hyperlocal, Route Optimization, Mobile Application (driver app, proof of delivery), Territory Optimisation, Shipsy BI, Finance Operations (COD reconciliation, customer remittance, bank deposits), Warehouse Management, EXIM (container and international), Digital Customer Experience, Vendor and Indent Management, Rates and Contracts, Rider Payout and Incentive, and Incident Management.

For the unified model, Shipsy is a shipment and location system of record, and in some deployments a COD settlement system too. It is not a sales channel and holds no listings. It is also frequently the counterparty on the other side of a carrier integration: several Indian aggregators run their carrier orchestration on platforms of this shape.

API access

There is no self-serve route. Credentials come from a commercial engagement.

• No public developer console, no signup, no published API reference, no pricing for API access, no partner tiers.
• The marketing site advertises an "APIs and Microservices" solution area and a "Live Tracking, via API" capability, but every link resolves to sales or to the knowledge base rather than to documentation.
• https://api.shipsy.io/ is live and answers with a JSON health body ({"started": ..., "uptime": ...}) but exposes no documentation index.
• Deployments are tenanted. The one public sample uses an organisation-id header whose value is a tenant slug, which implies per tenant hosts or per tenant routing across a shared gateway.
• No official SDK in any language. No Shipsy owned repositories were found on GitHub.
• The Integration Marketplace module is Shipsy's own in-product catalogue of connectors (ERP, WMS, commerce plugins, communication providers), configured by an operator in the panel rather than by code.

Authentication

The only publicly observable scheme comes from the EXIM container tracking collection published in Shipsy's Postman team workspace. It is a three header static credential, with no token exchange, no expiry and no refresh:

curl -X GET "https://eximapi.shipsy.in/track?shipmentType=CONTAINER&shipmentNumber=MRKU3495817" \
  -H "x-api-key: $SHIPSY_API_KEY" \
  -H "user-id: 123258" \
  -H "organisation-id: eximdemo" \
  -H "content-type: application/json"

Because the credential includes a user id, actions are attributable to a user inside the tenant, and permissions are presumably the same role model the panel uses. How keys are issued, rotated or scoped is not published.

Whether the core TMS and WMS modules use the same scheme is not published and must not be assumed. Multi account support means one key, user id and tenant slug per Shipsy tenant.

Objects we can read

Only one object is publicly documented.

Shipments and tracking (EXIM, container and freight)

GET https://eximapi.shipsy.in/track?shipmentType=CONTAINER&shipmentNumber={number}

shipmentType takes the tracked identity type. The companion write endpoints accept booking numbers, bills of lading and container numbers, so the tracked types are at least CONTAINER, and by implication bill of lading and booking. The response body is not published in the collection, so field names and the event history shape are unverified.

Everything else

Not published. From module names and knowledge base articles, the platform holds:

• Shipments and consignments with carrier status, carrier NDR reasons and custom status mappings (Multi-Carrier Management: "carrier tracking", "system default mapping carrier status mapping", "system default mapping carrier NDR mapping").
• Hubs, users and masters (Core Platform, 160 articles).
• Inventory, picking, packing and shelf management (Warehouse Management).
• COD reconciliation, customer remittance, bank deposit transactions and rider cash (Finance Operations and Finance Operations Advanced), which is the closest thing to settlements in the platform.
• Customer and vendor rate cards and tariffs (Rates and Contracts).
• Proof of delivery captured in the driver app (Mobile Application module).

None of these has a published endpoint, request shape, filter set or pagination model. Any connector work against them starts with a document from the Shipsy implementation team.

Writing back: listings, price and stock

Not applicable, this is a logistics platform. Shipsy holds no catalogue, price or stock in the retail sense (its WMS holds inventory, but that is warehouse stock, not channel listings).

The only public write path is registering shipments for tracking in the EXIM module, all on https://eximapi.shipsy.in:

• POST /add/container with a containerNumberList[] array.
• POST /add/bl with a blNumberList[] array.
• POST /add/bk with a bookingNumberList[] array.

Each array element carries the identifier plus the commercial context: shippingLine (an enum, with HAPAG and SAMUDERA among the published values), vendorCode, movementType (EXPORT or IMPORT), accessType (PUBLIC in the sample), teamNames[], customerName, customerCode, supplierName, ffName (freight forwarder), shipmentOwner, productDetailNames[], purchaseOrderNumberList[], invoiceNumberList[], demurrageFreeDays, detentionFreeDays, cfsFreeDays, promisedTransitDays, internalReferenceNumber, invoiceNumber and customerReferenceNumber.

Shipment creation, cancellation, label generation, pickup requests and NDR actions for the parcel side of the platform are not publicly documented. They exist (the panel does all of these) but the contract is not public.

Webhooks and notifications

Not published. The Communication Engine module handles SMS, email and notification templates for logistics events, but those go to end customers. Whether Shipsy can push shipment status to a customer endpoint, and with what verification and retry policy, is not documented publicly and must be asked during implementation.

Until that is answered, assume pull. For the EXIM module that means polling GET /track per tracked identity. Container milestones move on the scale of hours to days, so a 4 to 6 hour cadence is sufficient and a 15 minute cadence would be waste. For parcel shipments, no polling contract is public.

Rate limits and pagination

Not published. No rate limit figures, quota headers, burst allowance, 429 semantics, pagination model, page size or cursor appear in any public artifact. The one public read endpoint takes a single shipment number and returns a single result, so there is nothing to paginate there.

This is the single largest unknown for capacity planning: a tenant with hundreds of thousands of shipments cannot size a sync without a rate limit figure from Shipsy.

Mapping to the unified model

Only the EXIM tracking fields can be mapped with confidence. Everything else is inference from module names and must be confirmed.

Additional EXIM fields worth carrying in raw: demurrageFreeDays, detentionFreeDays and cfsFreeDays, which drive port and container penalty exposure and have no equivalent in the unified model.

Gaps and open questions

• The core parcel and TMS API is entirely unpublished: no endpoint list, no auth contract, no pagination, no rate limits, no webhook catalogue. Everything beyond EXIM container tracking needs a document from Shipsy.
• Whether x-api-key plus user-id plus organisation-id is the platform wide auth model or specific to the EXIM gateway is unverified. The EXIM host (eximapi.shipsy.in) is separate from api.shipsy.io, which suggests at least two gateways.
• No response body is published for the one readable endpoint, so even container tracking cannot be mapped field by field without a live key.
• No sandbox is advertised. The eximdemo tenant slug in the sample hints at a demo environment but it is not offered publicly.
• API key issuance, rotation, scoping and revocation are undocumented.
• Whether Shipsy can push status to a customer endpoint, and with what signature and retry policy, is unknown.
• The knowledge base is served at knowledge.shipsy.ai and states it is "sourced from helpcentre.shipsy.io", so there are two copies of the operator documentation and they may drift.
• The shippingLine enum is only partially visible (two values in samples). The full list matters for carrier normalisation.

Sources

• Shipsy product site
• Shipsy developers link, which resolves to the knowledge base
• Shipsy knowledge base, Integration Marketplace module
• Shipsy knowledge base, Multi-Carrier Management module
• Shipsy knowledge base, Finance Operations (Advanced) module
• Shipsy Exim API, public Postman workspace
• https://api.shipsy.io/ (live host, returns a JSON health body, no documentation)