Shipmaxx

ShipMaxx is Losung360's shipping module for Indian sellers, running a FastAPI backend with SSO login and no public documentation or OpenAPI document.

ShipMaxx is the shipping product inside Losung360, a Gurugram full-stack commerce operations company. Losung360 sells five things: SupplySphere for warehousing and fulfilment, ShipMaxx for shipping, SellerPro as a marketplace growth suite, StockBridge for distribution and ShipBulk for cargo. ShipMaxx is the multi-courier aggregator layer: centralised catalogue, order import from marketplaces, courier comparison and selection, multi-parcel shipments across several pickup locations, dispatch, tracking and buyer notifications. There is a live, versioned API behind the seller panel and no public documentation for it. This page records what is verifiable from outside.

At a glance

What it is

Losung360 Pvt Ltd, at 6th Floor, Tower A, Spaze I-Tech Park, Sector 49, Gurugram, Haryana 122001, contact contact@shipmaxx.in. The shipmaxx.in domain was registered on 2024-07-10, so the product is about fourteen months old, though Losung360 itself is older and operates physical warehouses and a fleet.

The distinctive thing about ShipMaxx relative to a pure aggregator is that it sits next to a real 3PL. Losung360 describes itself as "a full-stack operations and scale partner for all-size brands, simplifying fulfilment, shipping, marketplace growth, cargo movement, and compliance", with multi-located warehouses and fleet based logistics. So a seller can take shipping alone, or shipping plus storage and pick and pack.

Published ShipMaxx capabilities, read 2026-09-22:

Neither courier partners nor COD remittance timing nor NDR handling appears anywhere in the public material, including the FAQ, which is a notable omission for an Indian aggregator.

API access

No documentation is published. What exists, verified live on 2026-09-22:

The application API identifies itself without credentials:

{ "app": "ShipMax API Prod", "status": "Running", "version": "1.0.0" }

GET https://appapi.losung360.com/health returns {"status":"OK"}. Every other path returns {"detail":"Not Found"}, which is FastAPI's default 404 body, so the stack is Python and FastAPI. FastAPI normally serves interactive documentation at /docs and a machine readable specification at /openapi.json; both are disabled here, along with /redoc. That is the correct production setting, and it means no schema can be read from outside.

Route families visible in the panel's public JavaScript bundle, all under /api/v1:

Warning

That list is read from a public JavaScript bundle and is deliberately partial: the panel lazy loads most of its route code, so orders, tracking, NDR and finance calls live in chunks not fetched here. It is the panel's private interface, not a published product. Request bodies, response shapes, status vocabulary, error codes and stability are all unknown, and route names change with any panel deploy. Use it to know what to ask for, not to build against.

Two design details do carry over usefully. Carrier selection is configured as carrier variants with a toggle and a set of shipping rules, so a seller's available couriers are a per-account preference list rather than a global catalogue. And channels/custom/install implies a custom channel type exists alongside the packaged marketplace connectors, which is the most likely hook for a seller's own store.

The route to credentials is a seller account plus a conversation through shipmaxx.in/contact-us.

Authentication

Not published. What is observable: login runs through a separate SSO service at sso.losung360.com with ssoapi.losung360.com behind it, and the application API is a different host. An auth/send-otp route exists in the panel bundle, so one-time passwords are part of the sign-in flow, and auth/invite indicates multi-user accounts with invitations.

That split, a dedicated SSO issuing a credential that the application API then accepts, is the right shape for a machine client and suggests a token-based model is achievable. But no token endpoint, lifetime, refresh mechanism, scope model or header name is documented, and the production API exposes nothing unauthenticated beyond its identity and health. No code sample can be written honestly, and guessing credentials against a production host is not acceptable.

Companies are identified in paths as companies/{company_id}, so multi-account handling is probably one credential per company.

Objects we can read

Nothing without an account, and no schema is published for anything. What follows names what exists.

Orders

Imported from connected channels, named publicly only as Amazon, Shopify "and other popular marketplaces". The panel has an orders/create route for manual and bulk creation. ShipMaxx is not the system of record for a channel order; read those from the channel connector.

Order items

Implied by multi-parcel shipping, which requires knowing which items are in which box. Not documented.

Products and listings

ShipMaxx holds a centralised product catalogue, marketed as spanning multiple platforms, used to build shipments and to drive a product recommendation route. These are shipment-support products with SKU, dimensions and weight, not channel listings with a price and a stock level per marketplace.

Inventory

Genuinely present, unlike most aggregators. Losung360 runs warehouses, ShipMaxx bundles a mini warehouse system called Dispatch Ease and publishes an integrated WMS solution page, and the marketing claims real-time inventory management. So a real stock-by-location object exists for sellers who also use Losung360 fulfilment. No interface is documented.

Shipments and tracking

The core object: courier comparison, one-click dispatch, multi-parcel shipments across multiple pickup locations, label configuration per company, and buyer notifications on status change. Field names, status vocabulary and event history shape are not published. Sample response not published.

Returns, NDR and RTO

Not mentioned anywhere in public material, including the FAQ. For an Indian aggregator that is a conspicuous silence, and it is the first thing to ask about. Do not assume NDR workflows exist.

Proof of delivery

Not mentioned.

Payments and settlements

A Reconciliation solution page exists, which in this sector means freight invoice and weight reconciliation rather than COD remittance. COD is not discussed anywhere in public material, and no remittance cycle is published. Both need a direct answer.

Customers

Consignee name, address and phone travel on every shipment, and the platform sends buyers SMS and WhatsApp messages, so phone numbers are used actively. All PII. Nothing exposed.

Locations

Multiple pickup locations per seller are a headline feature, and Losung360 operates its own multi-located warehouses. Serviceability is quoted as 27,000 plus pincodes with no published lookup.

Writing back: listings, price and stock

Not applicable, this is a carrier and aggregator. ShipMaxx does not publish listings to a marketplace and does not set prices there.

The write path is the shipment lifecycle: import or create an order, compare couriers, pick one manually or let the rule engine pick, dispatch in one click, generate the label under the company's label configuration, and split into multiple parcels where needed. Carrier availability itself is writable as a preference, through the carrier variant toggle and the shipping rules, which is how a seller narrows the courier set before the selection logic runs.

None of it is documented as an interface. No request body, response shape or batch limit can be stated without inventing it.

Webhooks and notifications

No seller-facing webhook is published. The notifications ShipMaxx advertises are buyer-facing: order status updates by email, SMS and WhatsApp.

Until a contract says otherwise, assume polling. For an aggregator of this size, every 30 minutes for shipments in transit, every 6 hours for terminal states and daily for reconciliation is a sensible starting cadence, subject to whatever limit they state.

Rate limits and pagination

Not published. No quota header appeared on any unauthenticated response, and no page size is stated. The rate card routes take filter and filter-options parameters, which suggests server-side filtering rather than client-side paging, but the pagination model itself is unknown.

Mapping to the unified model

Field names are unknown, so the right column names the concept or the observed route.

Gaps and open questions

  • Is there a seller API product with its own credentials and a document, or only the panel's internal interface. This decides whether a connector is possible at all.
  • The ten plus courier partners are never named. Carrier attribution is impossible without that list.
  • NDR, RTO and reverse pickup are absent from all public material. Either they are unsupported or undermarketed, and the difference matters.
  • COD support and remittance cycle are not discussed anywhere.
  • The relationship between ShipMaxx and Losung360's own fulfilment arm is unclear from outside: whether inventory in a Losung360 warehouse is visible in the same panel and the same interface, or a separate system.
  • No rate limit, no pagination model, no sandbox, no changelog.
  • ShipMaxx does not appear in the ClickPost carrier directory or in Unicommerce's integration list, so there is no third-party description to cross-check against.

Sources

  • ShipMaxx homepage, read 2026-09-22, for the Losung360 ownership, the Gurugram address, the 27,000 pincode and 10 plus courier claims and the feature list
  • ShipMaxx sitemap, for the full set of solution pages
  • ShipMaxx multi-channel integration, which names Amazon and Shopify and mentions no API
  • ShipMaxx FAQ, for the AI-powered dynamic carrier selection wording and the absence of any COD, NDR or courier detail
  • Losung360 homepage, for the five product lines and the company positioning
  • The seller panel at https://app.losung360.com/ and its public bundle assets/index-BgbA-Bt0.js, read 2026-09-22, for the API hosts and the /api/v1 route families
  • Live unauthenticated HTTP checks on https://appapi.losung360.com/ and /health, and on https://ssoapi.losung360.com/, which return the identity and health objects quoted above, plus FastAPI 404s on /docs, /redoc and /openapi.json
  • DNS checks across the shipmaxx.in and losung360.com hostnames listed above, and whois for shipmaxx.in, for the 2024-07-10 creation date