Selloship

Selloship (Selloship Services) is an Indian shipping aggregator aimed at small and mid sized online sellers, resellers and dropshippers. It resells roughly fifteen courier networks (Blue Dart, Delhivery, Shadowfax, Ekart, Xpressbees, Shree Maruti, India Post and others) on a single account with a published rate card, and its commercial pitch is RTO reduction, daily COD remittance and an NDR desk staffed by people rather than automation. It matters to a seller as the shipping layer, not a sales channel: there is no catalogue, price or stock surface here at all. There is no developer portal, but the company ships an official WooCommerce plugin whose source documents a small, real and currently live API.

At a glance

What it is

Selloship is a courier aggregation and shipping software service for India, operating from selloship.com with a seller panel at selloship.com/v2/seller/. Its own plugin listing describes coverage of 26,000 plus Indian pincodes and 220 plus countries, fifteen or more courier partners, and rates starting at Rs 27 per 500 g. The homepage claims 5,000 plus sellers, up to 99.6 percent delivery ratio, RTO reduction of up to 96 percent, daily COD remittance and support from 6 am to midnight. This is a small player by Indian aggregator standards, an order of magnitude below Shiprocket or Delhivery's own seller product, and the claim set is marketing rather than audited.

The product is not D2C-only and not a marketplace: it is a seller side logistics tool. Its reseller and dropshipper positioning shows in the API shape, which creates one shipment per product line rather than per order.

The public rate card on selloship.com/shipping.html, read on 2026-09-22, lists per zone air rates for 500 g with COD charges, for example Shadowfax at Rs 37 intercity to Rs 73 for the North East with COD at Rs 30 or 2 percent whichever is higher, and Delhivery Express at Rs 61 intercity to Rs 109 for the North East with COD at Rs 65 or 2.5 percent. Those numbers will drift; they are quoted only to show that the rate card is published rather than quote-only.

API access

There is no developer programme, no API key console and no published reference. Every subdomain and path that would normally hold one was checked on 2026-09-22 and returns the platform's CodeIgniter "404 Page Not Found" page: docs.selloship.com, developer.selloship.com, apidoc.selloship.com, api.selloship.com, selloship.com/api/, www.selloship.com/api-documentation and www.selloship.com/developers.

What does exist is an official integration artefact: the Selloship WooCommerce shipping plugin, published by the "Selloship" contributor account on WordPress.org and mirrored on GitHub. Its source contains the endpoint constants, the exact request bodies and the exact Authorization header construction. That plugin is the de facto API documentation and the basis of this page.

Access route in practice:

1. Register a Selloship seller account at selloship.com/create_account.html.
2. The credentials that authenticate API calls are the same account email and password. There is no separate API key to generate, and nothing in the panel is documented as an API settings screen.
3. For anything beyond order creation and the tracking link, the route is a conversation with Selloship support. No partner tier, pricing or approval process is published.

No SDK, no Postman collection and no OpenAPI specification is published in any language. The plugin's own metadata says "Tested up to: 5.3", a WordPress version from 2019, so the plugin has not been refreshed in years even though the endpoints it calls still answer.

Authentication

Two steps, both POST with form encoded bodies.

1. Resolve the vendor id. POST https://selloship.com/api/lock_actvs/Vendor_login with Authorization: 1 (a literal constant, not a secret) and the form fields email, password, reg_form=3, device_id, app_status=3, device_from=3, site_url. On success the response is {"success":1,"msg":"...","data":[{"vendor_id":"..."}]}. Store vendor_id; it is stable per account.
2. Mint an access token. POST https://selloship.com/api/lock_actvs/Generate_vendor_token with the form body vendor_id=<id>&device_from=3 and the header Authorization: <md5(vendor_id . email)>, that is the MD5 hex digest of the vendor id string immediately followed by the account email with no separator. On success the response is {"success":"1","access_token":"..."}.
3. Call business endpoints with Authorization: <access_token> and Content-Type: application/x-www-form-urlencoded.

  step 1, resolve the vendor id
curl -X POST https://selloship.com/api/lock_actvs/Vendor_login \
  -H 'Authorization: 1' \
  -d 'email=seller@example.com' \
  -d 'password=<account password>' \
  -d 'reg_form=3' -d 'device_id=abcd' -d 'app_status=3' -d 'device_from=3' \
  -d 'site_url=https://store.example.com'

  step 2, mint a token, then call an endpoint with it
AUTH=$(printf '%s%s' "$VENDOR_ID" "$EMAIL" | md5 -q)
curl -X POST https://selloship.com/api/lock_actvs/Generate_vendor_token \
  -H "Authorization: $AUTH" \
  -d "vendor_id=$VENDOR_ID&device_from=3"

Verified behaviour of unauthenticated probes on 2026-09-22: Vendor_login returns HTTP 200 with {"success":"0","msg":"Invalid Email or Password"}, and /web_api/create_order returns HTTP 200 with {"success":"0","msg":"Some field is missing."}. Both endpoints are therefore live and both signal failure in the body while still returning 200, so a client must branch on success and never on the HTTP status.

Token lifetime, scopes and refresh are not published. The plugin mints a fresh token immediately before each batch of order pushes and never caches it, which is the safe pattern to copy. Multi account handling is one email, password and vendor id triple per seller.

Objects we can read

Very little is evidenced, and this is the main finding of the page.

Shipments and tracking

POST https://selloship.com/web_api/wordpress_track with the form body order_id=<selloship order id>&vendor_id=<id> and no Authorization header at all. The response is {"success":"1","data":[{"tracking_url":"..."}]}; when no courier has been allocated yet, success is not 1 and the plugin surfaces "No Courier Assigned!".

This returns a link to a white labelled tracking page, not an event history. There is no evidenced endpoint that returns AWB, carrier, scan events, timestamps, proof of delivery, NDR reason or RTO status as structured data. Whatever the panel shows, it is not reachable through any documented call.

Rates and serviceability

Not an API. The public page selloship.com/shipping.html drives a widget at GET https://selloship.com/welcome/zipcode_availibity_check?vendor_zipcode=<pin>&zip_code=<pin>&vendor_id=<id>, which was confirmed on 2026-09-22 to answer unauthenticated with an HTML table fragment (Content-Type: text/html) listing available partners and their pickup, COD and prepaid flags. A related GET https://selloship.com/welcome/zipcodebyalldetails appears on the same page. These are website internals: no JSON, no versioning, no contract, and scraping them is fragile. Use the published rate card and the widget for manual checks, and ask Selloship for a real serviceability endpoint before depending on one.

Orders, order items, products, inventory, returns, settlements, customers, locations

No read endpoint is evidenced for any of these. The plugin pushes orders out and never reads them back, so even the Selloship side order id and any assigned AWB have to be captured from the create order response or recovered from the panel. Daily COD remittance is a marketed feature with no accompanying API.

Writing back: listings, price and stock

Not applicable, this is a carrier. Selloship holds no listings, no price and no stock, so there is nothing to write back. The write path is shipment creation.

Create. POST https://selloship.com/web_api/create_order, Authorization: <access_token>, Content-Type: application/x-www-form-urlencoded, with these fields as sent by the official plugin:

Two structural consequences matter. First, the request is per product line, not per order: the plugin loops over the WooCommerce line items and calls create_order once per item, so a three line order becomes three Selloship orders. Any connector has to decide whether to mirror that or to collapse lines, and must expect its own custom_order_id to appear several times. Second, there is no weight, no dimensions, no package block and no courier selection field in the evidenced body, so Selloship must be deriving weight and carrier choice from account level configuration rather than from the request.

Cancel, pickup, label, manifest, NDR action, return creation. None is evidenced. The plugin does not call them and no reference documents them. The plugin's own instructions describe the physical flow as: shipping documents arrive by email for every order, the seller prints and affixes them, and the courier collects. That strongly suggests label delivery is by email and pickup scheduling is automatic or panel driven rather than API driven, but that is an inference and should be confirmed.

Catalogue and stock sync. The plugin listing does advertise "Catalog and inventory Sync", with active WooCommerce products fetched into Selloship and their stock counts manageable from the Selloship panel. That is a panel feature operating over the WooCommerce REST API in the other direction (the setup instructions require enabling WooCommerce's Legacy REST API), not a Selloship API a third party can call. It does not make Selloship a place to write listings, price or stock.

Webhooks and notifications

None published, and none referenced anywhere in the plugin source. There is no subscription endpoint, no event catalogue, no signing secret and no callback registration. wordpress_track requires no authentication, which also means there is no signature to verify on anything.

What to poll instead, given the constraints:

• POST /web_api/wordpress_track per Selloship order id. Since it returns only a URL, the useful signal is binary: "a courier has been allocated" versus "not yet". Every one to two hours is enough to detect allocation.
• For anything past allocation (dispatch, scans, delivery, NDR, RTO), there is no pull route. Either negotiate a real tracking API with Selloship, or track directly with the carrier once the AWB is known, or fall back to the panel and its email reports.

Do not build a status pipeline on the white labelled tracking page HTML. It is a marketing surface, will change without notice, and scraping it would put customer PII through an unversioned parser.

Rate limits and pagination

Neither is published, and neither can be inferred from the plugin, which makes only a handful of calls per order batch. There are no quota headers, no documented throttling response and no retry guidance. Note also that the endpoints return HTTP 200 on failure, so a throttle would most likely arrive as a success: "0" body with an opaque msg rather than a 429.

Pagination does not arise: there is no list endpoint of any kind. Every evidenced call is a single object write or a single object lookup by identifier.

Practical cadence: serialise per seller, mint a token per batch as the plugin does, keep concurrency at one or two, and back off on any non-JSON response or HTML error page.

Mapping to the unified model

Only the write side and a single tracking link can be mapped with confidence.

Gaps and open questions

• No published API reference at all. Everything here is from the vendor's own WooCommerce plugin plus live probes, so field coverage is whatever that one integration needed.
• The create order response shape is unknown beyond success and msg. Critically, it is not established whether it returns a Selloship order id, and wordpress_track needs one. That single unknown blocks a working integration and is the first question to put to Selloship.
• No structured tracking. No AWB, carrier, scan list, timestamps, proof of delivery, NDR reason code or RTO state is retrievable through any evidenced call.
• No cancel, pickup, label, manifest, NDR action or return creation endpoint is evidenced, even though all of those exist as panel features.
• No serviceability or rate API. The only machine readable route is an unauthenticated HTML widget on the marketing site.
• No COD remittance data, despite daily remittance being a headline feature.
• Token lifetime, rate limits, error code list and any sandbox are all unknown.
• The plugin has not been updated since roughly WordPress 5.3, yet the endpoints it calls still answer. Whether those are the current endpoints, or a frozen legacy path kept alive for old plugin installs, cannot be determined from outside.
• The authentication scheme (account password as the API secret, unsalted MD5 of non secret values as the pre-auth header, HTTP 200 on failure) is below what a production credential store should accept without compensating controls.

Sources

• Selloship WooCommerce plugin source, WordPress.org mirror: selloship.php for the endpoint constants, request bodies and callAPI header construction, includes/class-selloship-woocommerce-shipping-method.php for the Vendor_login request body, readme.txt for the coverage and feature claims. Read on 2026-09-22
• Selloship homepage for the seller count and service claims
• Selloship shipping partners and rate card for the carrier list, per zone rates and the pincode widget
• Live probes on 2026-09-22 confirming POST /api/lock_actvs/Vendor_login, POST /web_api/create_order and GET /welcome/zipcode_availibity_check answer, and that docs., developer., apidoc. and api.selloship.com all return the platform 404