RapidShyp

RapidShyp is an Indian shipping aggregator: a seller keeps one account and one API integration, and RapidShyp brokers the shipment out to one of roughly fifteen courier partners (Blue Dart, Delhivery, DTDC, Ekart, Amazon Shipping, India Post and others) according to a rate and priority rule set. For a seller it is the layer that turns "I have an order with an address" into an AWB, a label PDF, a scheduled pickup and a stream of tracking scans, without a separate contract per carrier. It has real, public, first party API documentation, which is unusual for this segment.

At a glance

What it is

RapidShyp is a courier aggregator and shipping software platform for Indian e-commerce sellers, operating a self serve panel plus a public API. Its marketing pages claim over 400,000 sellers and 15 or more courier integrations as of April 2026. It is not a marketplace and not a carrier: it resells and orchestrates third party courier capacity, adds an AI courier recommendation layer, an order verification and COD confirmation product, a fulfilment offering, and a B2B cargo arm branded CargoPlus. Channel integrations exist for the usual storefronts, so the API described here is the custom channel route for sellers whose order source is their own system.

The important structural fact for a connector is that RapidShyp models an order as containing one or more shipments, and almost every operational call is keyed on shipment_id, not on the order. An order with items split across pickup locations becomes several shipments, each with its own AWB.

API access

The key is self serve from inside a RapidShyp seller account. The documented path is Setting, then Configure API, then Generate New API Key. The key is shown once and must be stored at that point. No developer registration, partner tier or approval step is described, and no cost is attached to API access itself beyond the normal shipping charges.

• API version in force is v1 in the path. The B2C tracking page carries a v1 and a v2 tab, with v1 marked "Latest" as of September 2026, so v2 appears to be in preparation rather than in force. No deprecation schedule is published.
• No official SDK in any language, and no Postman collection, is published. Every documented example is a cURL command.
• Support contact for integration issues is techsupport@rapidshyp.com or a ticket raised from the panel.
• Separate B2C and B2B (CargoPlus) endpoint families exist, with parallel create order, AWB assign, label, cancel and tracking calls. Serviceability has three variants: B2C, B2B and return.

Authentication

There is no token exchange. Authentication is a single static secret on every request.

1. Log into the RapidShyp seller panel.
2. Go to Setting, then Configure API, then Generate New API Key.
3. Save the generated key. The documentation shows it as a long hex string, for example e779a465...4b64805e, though at least one example in the docs shows a short mixed character key, so do not assume a fixed length or charset.
4. Send it on every call as the header rapidshyp-token, alongside Content-Type: application/json.

No token lifetime, rotation policy, scope model or refresh endpoint is documented. Multi account handling is one key per RapidShyp seller account; there is no concept of an app acting on behalf of several sellers, so a connector must store one key per seller.

curl --location 'https://api.rapidshyp.com/rapidshyp/apis/v1/serviceability_check' \
  --header 'rapidshyp-token: <API-KEY>' \
  --header 'Content-Type: application/json' \
  --data '{"Pickup_pincode":"201301","Delivery_pincode":"110001","cod":true,"total_order_value":2000,"weight":1}'

curl --location 'https://api.rapidshyp.com/rapidshyp/apis/v1/shipment_details?shipment_id=1111111111' \
  --header 'rapidshyp-token: <API-KEY>' \
  --header 'Content-Type: application/json'

Objects we can read

Orders and order items

GET /rapidshyp/apis/v1/get_orders_info?order_id={id}&channel_order_id={id}

These are orders as RapidShyp holds them (pushed in by the seller or pulled from a connected channel), not marketplace orders. The response nests shipment_lines[], each with its own item_lines[], AWB and courier, which is where the order to shipment split becomes visible.

{
  "status": "SUCCESS",
  "seller_order_id": "1111111111",
  "channel_order_id": "1111111111",
  "order_status": "PROCESSING",
  "store_name": "DEFAULT",
  "order_created_date": "2025-09-10",
  "payment_method": "COD",
  "shipping_is_billing": true,
  "shipping_address": {
    "shipping_name": "aabcs", "shipping_contact": "9999999999",
    "shipping_address": "Delhi New Delhi", "shipping_city": "NEW DELHI",
    "shipping_pin_code": "110001", "shipping_state": "DELHI", "shipping_country": "INDIA"
  },
  "shipment_lines": [
    {
      "shipment_id": "1111111111",
      "pickup_address_name": "Dumbell",
      "item_lines": [
        { "item_name": "Mobile", "sku": "SKU123", "units": 3, "unit_price": 88.0, "discount": 6.0, "hsn": "HSN123", "tax": 0.0, "shipping_charges": 12.0, "selling_price": 264.0 }
      ],
      "shipping_charges": 20.0, "gift_wrap_charges": 30.0, "transaction_fee": 20.0,
      "discount": 10.0, "total_prepaid_amount": 0.0, "sub_total": 440.0,
      "cod_charges": 33.92, "total_shipment_value": 500.0,
      "awb": "1111111111111", "courier_code": "7002", "courier_name": "EKart Surface 2 Kg",
      "parent_courier_name": "Ekart", "applied_weight": 1600.0,
      "routing_code": "PaharganjHub_DEL", "rto_routing_code": "PaharganjHub_DEL",
      "tracking_link": "https://abc.com/t/1111111111"
    }
  ]
}

Addresses and customer contact fields are PII and are returned unmasked. There is no list or date window query documented, so orders can only be fetched one at a time by id, which makes a local order id ledger mandatory.

Shipments and tracking

GET /rapidshyp/apis/v1/shipment_details?shipment_id={id} returns one shipment with the pickup and RTO warehouse blocks, dimensions, dead_weight and applied_weight, shipment_status, awb, courier_name, child_courier_name, awb_assigned_date, the latest NDR triple, and a final_freights object:

{
  "success": true,
  "shipment_details": {
    "shipment_id": "1111111111",
    "shipment_creation_date": "12-08-2025 16:01:42",
    "total_shipment_value": 500.0,
    "collectable_amount": 500.0,
    "length": 20.0, "breadth": 10.0, "height": 5.0,
    "dead_weight": 1600.0, "applied_weight": 1600.0,
    "shipment_status": "ASSIGNED",
    "awb": "1111111111111",
    "courier_name": "DTDC", "child_courier_name": "DTDC Surface 2 Kg",
    "awb_assigned_date": "17-09-2025 10:57:30",
    "final_freights": {
      "total_freight_forward": 88.78, "total_cod_charges": 23.36,
      "total_rto_freight": 0.0, "total_extra_fwd_freights": 0.0,
      "total_extra_rto_freights": 0.0, "total_insurance_charge": 0.0,
      "total_freight": 112.14
    },
    "current_courier_edd": null,
    "current_tracking_status_code": null,
    "current_tracking_status_desc": null,
    "current_status_date": "17-09-2025 10:57:30",
    "latest_ndr_reason_code": null,
    "latest_ndr_reason_desc": null,
    "latest_ndr_date": null
  }
}

POST /rapidshyp/apis/v1/track_order is the event history call. It takes either awb, or orderId plus one of contact or email as a weak ownership check, and returns records[], each an order with shipment_details[], and each shipment carrying product_details[], track_scans[], delivered_date and rto_delivered_date. The published samples show track_scans as [] or null for shipments that have not moved, so the per scan field names are not evidenced in the documentation. A B2B variant exists on the same pattern. Timestamps in this API are DD-MM-YYYY HH:MM:SS strings, unlike the YYYY-MM-DD used on order dates, so parsing must be per field.

Dates are strings, not ISO 8601, and there is no timezone marker anywhere in the samples. Assume IST.

Rates and serviceability

POST /rapidshyp/apis/v1/serviceability_check with Pickup_pincode, Delivery_pincode, cod (boolean), total_order_value and weight in kilograms. This is the rate card call as well as the serviceability call: each entry carries a price.

{
  "status": true,
  "remark": "Success",
  "serviceable_courier_list": [
    {
      "courier_code": "6001",
      "courier_name": "BlueDart Express",
      "parent_courier_name": "BlueDart",
      "cutoff_time": "14:00",
      "freight_mode": "Surface",
      "max_weight": 5000.0,
      "min_weight": 1.0,
      "total_freight": 11.111,
      "edd": "17-09-2025",
      "epd": null
    }
  ]
}

courier_code from this response is what gets passed to AWB assignment. There are separate B2B and return serviceability endpoints documented under the same section.

Returns and cancellations

Reverse shipments are created, not read: POST /rapidshyp/apis/v1/create_return builds a return order where the customer address is the pickup and the seller warehouse is the delivery, with an optional return_reason_code (blank defaults to "others") and a comment. It returns order_id and a shipment[] array with shipment_id, total_value and shipment_items[]. A separate POST schedule pickup exists under the Return API section. Tracking of a return uses the same track_order call, which the documentation titles "Forward or Return".

Locations

GET /rapidshyp/apis/v1/fetch_pickup_location lists the seller's pickup warehouses with pickup_name, contact_name, contact_number, contact_email and address lines. POST /create_pickup_location and POST /update_pickup_location manage them. A pickup location can also be created inline on the create order call, in which case the RTO address defaults to the new pickup address.

Payments and settlements

Not exposed. Freight is visible per shipment in final_freights (forward, COD charges, RTO, extras, insurance, total), and collectable_amount carries the COD value to collect, but there is no wallet balance, invoice, statement or COD remittance endpoint in the documentation. COD remittance reconciliation has to come from the panel.

Products and inventory

Not applicable. Item rows exist only as lines on an order.

Writing back: listings, price and stock

Not applicable, this is a carrier aggregator. RapidShyp holds no catalogue, no price list and no stock. The write path is the shipment lifecycle, and it is unusually complete.

Create order takes orderId, orderDate (YYYY-MM-DD), either pickupAddressName (an existing location) or an inline pickupLocation block, an optional rto_Location, storeName ("DEFAULT" for a single custom channel), billingIsShipping, shippingAddress, conditional billingAddress, an orderItems[] array (itemName, sku, units, unitPrice, tax, hsn, product dimensions in cm, productWeight in grams, brand, imageURL, isFragile, isPersonalisable, and an optional per item pickupAddressName), paymentMethod (PREPAID or COD), the charge fields (shippingCharges, giftWrapCharges, transactionCharges, totalDiscount, codCharges, prepaidAmount) and packageDetails with dimensions in cm and packageWeight in grams. It returns {"status":"SUCCESS","order_id":"ORD12345","shipment":[]}.

Validation is strict and worth encoding client side: phone numbers must start with 6, 7, 8 or 9; pincodes must be six digits; address line 1 must be 3 to 100 characters; first plus last name must be 3 to 75 characters; item name 3 to 200 characters. Setting pickupAddressName on individual items is what splits one order into several shipments.

Assign AWB takes shipment_id and an optional courier_code; leaving the code out lets the seller's configured courier rule or priority choose. It returns the AWB, the chosen courier, applied_weight, rto_routing_code, payment_method, total_order_value and collectable_amount.

Schedule pickup takes shipment_id and optional awb and returns the routing codes. Generate label is documented as a GET that nonetheless carries a JSON body {"shipmentId":["1111111111"]} and returns a labelData[] array of presigned S3 labelURL values, so it is a batch call. Sending a body on a GET is unusual and some HTTP clients strip it; verify behaviour before relying on it.

NDR action takes awb and action. The parameter table documents the values as RE_ATTEMPT and RETURN while the cURL sample sends REATTEMPT. The two contradict each other and must be confirmed with RapidShyp support before going live. For a reattempt, phone, address1 and address2 carry the corrected delivery details.

Wrapper is the one shot path: create order, create shipment, run serviceability, apply the courier rule, assign AWB, generate the pickup manifest, and generate label, invoice and manifest PDFs, in a single call. B2B and return variants exist. For a high volume connector this is the endpoint to build against, with the individual calls kept for repair and retry. Note the documented constraint that unitPrice and totalOrderValue are mutually exclusive in the request body.

Webhooks and notifications

No webhook, callback or push notification mechanism appears anywhere in the RapidShyp API documentation as of September 2026. There is no subscription endpoint, no event catalogue, no signature header and no retry policy. The panel may offer something, but it is not documented, so a connector must assume pull only.

Recommended polling, given there is no bulk or delta query:

• Maintain a local table of open shipment_id values from create order and AWB assignment responses.
• Poll POST /track_order by awb for every shipment that is not in a terminal state. Every 30 to 60 minutes is a reasonable cadence for surface shipments given that carrier scans themselves arrive in batches.
• Poll GET /shipment_details when the freight numbers matter, since final_freights and the NDR triple live there rather than in the tracking response.
• Stop polling on delivered_date, rto_delivered_date or a cancelled status, then do one last read to capture final freight.

Because no rate limit is published, keep concurrency low and add exponential backoff on any 429 or 5xx.

Rate limits and pagination

Neither is documented. No quota headers, no burst or sustained numbers, no per key or per seller ceiling, and no published response code for throttling. Equally, there is no pagination anywhere, because there is no list endpoint that could need it: orders, shipments and tracking are all fetched by identifier, and the two list style calls (fetch pickup location, serviceability) return a bounded array.

Practical consequences:

• There is no backfill route. History can only be rebuilt from identifiers already held locally, so record every order_id, shipment_id and awb at the moment it is issued.
• Batch where the API allows it: label generation accepts an array of shipment ids, and the wrapper call collapses six or seven round trips into one.
• Treat unspecified limits as strict. Serialise per seller key, and cache serviceability results, since a rate quote for a pincode pair, weight and COD flag is stable over minutes and is the call most likely to be hammered.

Mapping to the unified model

Gaps and open questions

• No webhooks at all. For a shipping integration that is the single largest gap: every status change has to be discovered by polling, with no published rate limit to size that polling against.
• No rate limits, quota headers or throttling response documented.
• track_scans[] is the object that matters most for shipments.events[], and its element schema is never shown filled in. The field names for scan status, location and timestamp have to be discovered against a live account.
• The NDR action enum contradicts itself between the parameter table (RE_ATTEMPT, RETURN) and the cURL sample (REATTEMPT).
• No return reason code sheet is published, only a reference to one.
• No sandbox is mentioned anywhere. Testing appears to require a real funded account, and AWB assignment is a billable action.
• Two host typos and one missing letter in endpoint paths appear in the published cURL samples, and several tracking pages 404 outright, which suggests the documentation is not continuously verified against the build.
• The v2 tracking tab exists but is undated and undescribed, so there is no migration window to plan for.
• Whether a proof of delivery artefact (signature, photo) is retrievable is not addressed anywhere.

Sources

• RapidShyp API overview and Authentication
• Create order, get order info, get shipment details, assign AWB, schedule pickup, label PDF, NDR action, wrapper, create return, fetch pickup location and B2C serviceability pages under docs.rapidshyp.com/docs/api-documentation/, read on 2026-09-22
• B2C Tracking API, reachable only under the DocumentationSidebar path
• RapidShyp courier integrations for the carrier list and the seller count claim