TekiPost, operated by Tekies Retail Pvt. Ltd., is an Indian multi-carrier shipping aggregator. A seller pushes orders over an API or a connected store, TekiPost allocates one of its contracted couriers (Delhivery, Ecom Express, Gati, Ekart and others), returns an AWB and a label URL, and relays courier scans back as one normalised tracking feed. It covers B2C parcel and B2B part-load, and settles cash on delivery weekly or twice weekly by plan. For a seller it matters as a carrier abstraction: one credential and one shipment schema instead of one integration per courier.
The API is real and reachable. There is a first-party Postman collection, "TEKI POST API V2", linked from the public developer page, and the production host answers unauthenticated calls with a structured error rather than a 404, which confirms the routes exist.
At a glance
What it is
TekiPost is a shipping aggregator, not a courier: it owns no line haul and resells capacity on Indian carriers. Its about page gives a 2022 founding, 8,000 or more sellers, 50 or more staff and four offices, with Pawan Srivastava as co-founder and CEO. The footer entity is Tekies Retail Pvt. Ltd.
The product surface is the standard Indian aggregator set: shipping management, real-time tracking, warehousing and pick-pack-ship from TekiPost centres, returns and reverse logistics, NDR recovery, analytics, express and standard domestic, B2B part-load, and COD. Published list pricing on 2026-09-22 is a flat 29 rupees per 500 grams on Basic, Growth and Pro alike, Enterprise quoted, with COD remittance once a week on Basic and Growth and twice a week above. The same figure on three tiers looks like a placeholder, so treat it as indicative only.
The architectural fact that matters is that TekiPost is a rate-and-allocate layer. Its quote endpoint returns one priced option per contracted courier with the full Indian freight breakdown (freight, fuel surcharge, ODA, risk cover, green tax, minimum LR billing), and shipment create either takes an explicit logistic_id or lets TekiPost choose.
API access
- Credentials come from the merchant dashboard at
app.tekipost.com, or from support on request. There is no developer console, no app registration and no client identifier. - "Custom Api" appears on the Growth, Pro and Enterprise plans on the public pricing page as of 2026-09-22 and not on Basic, so expect API access to be plan-gated.
- Versioning: the collection is named "TEKI POST API V2" but no version segment appears in any path, and there is no changelog, deprecation notice or version header. A silent breaking change is possible, so log unrecognised response shapes rather than assume stability.
- No official SDK in any language. The Postman collection is the whole of the published developer material.
- One sample request carries a
Cookie: PHPSESSID=...header alongside the bearer token, suggesting a PHP application with the API bolted onto the same session-based app. Do not send a cookie: the bearer token is the documented credential.
Authentication
POST https://app.tekipost.com/api-loginwith a JSON body holding the merchant's dashboardemailandpassword.- The response carries
data.token, a JWT. The published sample token decodes to a header of{"typ":"JWT","alg":"HS256"}and a body of{"user_id":"1"}, so it is a symmetric HS256 JWT whose only claim is the numeric user identifier. - Send it as
Authorization: Bearer <token>on every later request.
The published token has no expiry claim, no issued-at claim and no audience, so either tokens do not expire or expiry is enforced server side against a stored record. Neither is documented. Build the credential store to re-login on any response with success: false and a message resembling unauthantication, and do not assume a refresh endpoint exists, because none is published.
The credential is the merchant's own dashboard email and password, so there is no delegated authorisation model. Multi-account means one email and password pair per seller and one token per seller. There are no scopes and no roles.
curl -X POST https://app.tekipost.com/api-login \
-H 'Content-Type: application/json' \
-d '{"email":"DEMO@gmail.com","password":"1234567890"}'
{ "message": "Login Success", "response": 1, "success": true,
"data": { "token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoiMSJ9.H3KV6G5nxSOZRDEloX8wcAwce0b_OJMEbIQzvTjXznY" } }
An authenticated call, and the exact error the live host returned without a token on 2026-09-22:
curl -X GET https://app.tekipost.com/api-tracking-details/17127511114046 \
-H 'Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9...'
# with no Authorization header the same route returns HTTP 200 with
# {"message":"unauthantication","response":0,"success":false}
Note the envelope: every response carries message, response (1 or 0) and success, with the useful part under data. Failures come back with HTTP 200 and success: false, so branch on the body, never on the status code.
Objects we can read
Orders
POST /api-order-shipment-detail, the one route that takes multipart/form-data rather than JSON, with a single field order_no. No sample response is published, so its schema is unknown. Treat the shipment read below as the reliable one.
The collection also publishes the order status vocabulary as a flat list rather than an endpoint: Created, In Transit (pickup done), Reached at Destination, Dispatched (out for delivery), Delivered, Cancelled, Not Picked, RTO Manifested, RTO Processing, RTO In Transit, RTO Dispatched, RTO Delivered, LOST (lost and no response), NDR (non delivered report) and OTP Verified Cancellation. One vocabulary covers forward flow, RTO and NDR, so those are visible in the tracking feed as statuses but have no dedicated endpoint.
Order items
Order items exist only on the way in, inside the productdetatis array of the create calls. Note the spelling, which the API uses as published. No read endpoint returns them.
Products and listings
None. TekiPost is a carrier layer and holds no catalogue.
Inventory
None published. TekiPost sells warehousing as a service, but no inventory endpoint exists.
Shipments and tracking
GET /api-tracking-details/{awb}. The AWB goes in the path, there are no query parameters, no pagination and no bulk or date-window variant. One call per waybill.
{ "message": "Success", "response": 1, "success": true,
"data": {
"airwaybill_no": "17127511114046",
"status_name": "Delivered",
"delivery_date": "2025-02-08",
"tracking_detail": [
{ "scan_date_time": "2025-02-05 12:27:13", "scan": "In Transit",
"location": "Noida_Bairangpur_GW (Uttar Pradesh)", "remark": "Shipment picked up" }
]
} }
The event feed is two-level: scan is the coarse status from the vocabulary above, remark is the courier's free-text sub-status ("Manifest uploaded", "Pickup scheduled", "System weight captured", "Added to Bag", "Bag Added To Trip", "Trip Arrived", "Vehicle delayed"). Timestamps are naive local strings with no timezone, so read them as Asia/Kolkata. Locations are courier facility codes with the state in brackets, not structured fields.
Rates and serviceability
POST /api-calculate-price is the quote endpoint and the only serviceability signal published. It takes origin and destination pincodes and returns one priced option per available courier. There is no pincode serviceability route, so serviceability must be inferred: a pincode pair with no courier in the response is not serviceable.
{ "paymentMode": 0, "pickupPinCode": 360001, "deliveryPinCode": 362630,
"multiChecked": "off", "apprWeight": 1.5,
"b2c_length": 1, "b2c_breadth": 2, "b2c_height": 3,
"total_Weight": 0.5, "declaredValue": 10,
"box_shipment": [ { "no_of_box": 1, "length": 1, "breadth": 1, "height": 1, "each_box_weight": 1 } ] }
Response, trimmed to one courier:
{ "message": "Success", "response": 1, "success": true,
"data": {
"api_type": "1",
"heavy_rates": { "list": { "27": {
"logistic": "Delhivery N", "logistic_id": "27", "sub_total": 200,
"addittional_charges": {
"weight": "20", "zone": "W2-W2", "freight_charge": 200, "fuel_surcharge": 50,
"fuel_linkage": 2, "cod_charge": 0, "processing_charges": "150", "oda_amount": 0,
"rov_owner_risk_charge": "100", "green_tax_amount": 0, "first_mile_charge": "100",
"appointment_charge": 0, "minimum_lr_billing_amount": "400", "total_cost": 602
},
"cod_charge": 0,
"tax": { "TOTAL_TAX_AMMOUNT": 108.36, "CGST": 54.18, "SGST": 54.18, "IGST": 0 },
"gst_tax": 108.36, "total": 710.36
} } }
} }
Two parsing traps. data.heavy_rates.list is an object keyed by logistic_id as a string, not an array, so iterate the keys. And money arrives inconsistently typed: freight_charge is a number, processing_charges is a string, and the keys are spelled addittional_charges and TOTAL_TAX_AMMOUNT. Parse defensively and cast. api_type and the heavy_rates grouping imply other rate groups exist for lighter consignments, but only this shape is published.
POST /api-logistic-price/{tekipost_order_id} returns courier options for an already created order, which is how a seller picks a carrier after the fact. The only published sample is the empty case, {"message":"No Logistic Available Right Now, Please Try Again!!","response":0,"success":false}. Known courier identifiers from the collection: Gati 26, Delhivery 27, Ekart 29, with courier_name values of ECOM and DELHIVERY also seen.
Returns and cancellations
No dedicated endpoint. Returns are visible only as the RTO Manifested through RTO Delivered statuses in the tracking feed, and NDR as a status. Reverse pickup creation is not published. Every create call does accept a full return address block (return_consignee_name, return_mobile_no, return_address, return_pincode, return_city, return_state, return_landmark, or return_address_same_as_pickup_address: 1), which is where an RTO lands.
Payments and settlements
None published. COD remittance is marketed, weekly or twice weekly by plan, but there is no remittance, wallet or invoice endpoint. Settlement must come from the dashboard.
Customers
No customer object. Consignee PII travels on the shipment as consignee_name, mobile_no, alternate_mobile_no, email_id, receiver_address, receiver_pincode, receiver_city, receiver_state and receiver_landmark, all unmasked.
Locations
POST /api-warehouse-add creates or updates a pickup location and echoes the stored record: id, warehouse_name, contact_person_name, contact_no, address_line_1, address_line_2, landmark, pincode, city, state. Passing id updates an existing warehouse. There is no list or get endpoint, so a connector must keep its own map of sender_address_id values.
Writing back: listings, price and stock
Not applicable, this is a carrier. TekiPost holds no catalogue, so there is nothing to write listings, price or stock to. The write path is shipment creation and cancellation.
Two flags control two-step versus one-step behaviour on the single-order routes. isorder: 1 puts the order straight into the ready-to-ship bucket, and logistic_id: <n> forces a specific courier. The collection is explicit that each field must be omitted entirely, not set to zero or null, when the behaviour is not wanted.
B2C quick shipment, trimmed, with the product array cut to one item:
{ "consignee_name": "test", "mobile_no": 12345678904, "email_id": "test@gmail.com",
"receiver_address": "testadress", "receiver_pincode": 132001,
"receiver_city": "KARNAL", "receiver_state": "haryana",
"customer_order_no": "676e3783abc", "order_type": "1",
"product_quantity": 10, "cod_amount": 200, "physical_weight": 1,
"product_length": 21, "product_width": 22, "product_height": 12,
"hsn_number": "12e34", "order_value": 43,
"productdetatis": [ { "sku_number": 765, "product_name": "test 1", "product_quantity": 3, "product_value": 1233 } ],
"sender_address_id": 25, "return_address_same_as_pickup_address": 1 }
order_type is the payment mode: "0" prepaid, "1" COD, with cod_amount 0 for prepaid.
The quick-shipment response is the only place the API hands back an AWB and a label:
{ "status": 1, "message": "Successful", "tracking_number": "17127511477501",
"courier_name": "DELHIVERY",
"label_url": "https://app.tekipost.com/api-shipping-label-slip/37046",
"freight_charges": "122.72" }
That response uses a different envelope (status, not response and success) from every other route. The label_url identifier is neither the AWB nor the order_id from the other routes, so capture it verbatim.
Cancellation is POST /api-delete-order with {"awb_no": 16137216127030}. No sample response is published, so the confirmation shape is unknown.
There is no published route for a pickup request, a manifest, a bulk create or a label reprint by AWB. Pickup appears implicit in creation, since the tracking feed shows "Pickup scheduled" as a courier remark right after manifest upload.
Webhooks and notifications
Not published. Nothing in the collection or on the developer page describes a subscription, an event list, a signing secret or a retry policy. TekiPost does market email and SMS notifications to the buyer on every plan, and a white-label tracking page on Growth and above, but those are buyer-facing, not a machine feed.
Poll instead, with GET /api-tracking-details/{awb} per open waybill. There is no bulk variant, so the cost is one request per shipment per poll. Given no published rate limit, a defensible cadence is every 30 minutes for shipments in a moving state (In Transit, Dispatched, NDR, any RTO *), every 6 hours for Created and Not Picked, and stop once Delivered, Cancelled, RTO Delivered or LOST is reached. Back off hard on any success: false. Ask support whether a push callback exists before building the poller at scale, since most Indian aggregators of this size have an undocumented webhook they will configure on request.
Rate limits and pagination
No rate limit is published: no numbers, no quota headers, no burst policy, no statement of per-account or per-app scope. Assume nothing and throttle yourself.
Pagination does not exist anywhere in the published API. Every read is a single-record lookup by AWB or order number. There is no list endpoint, no date window, no cursor and no page parameter, which has a hard consequence: TekiPost cannot be backfilled or reconciled from the API alone. The set of shipments to poll must come from our own order records or from create-call responses, and a shipment created in the dashboard rather than over the API is invisible to us until someone tells us its AWB.
Mapping to the unified model
Gaps and open questions
- No webhook surface is published. Given a polling cost of one request per waybill, this is the first question for support.
- No rate limit is published at all, so a bulk backfill could trip an undocumented throttle or a WAF.
- No list endpoints anywhere, so the API cannot be reconciled against itself. Confirm whether an order list or date-window search exists undocumented.
- Token lifetime is unknown: the published JWT has no
exp. Confirm whether tokens expire, whether concurrent tokens are allowed, and whether a refresh route exists. POST /api-order-shipment-detailhas no published response and is the onlymultipart/form-dataroute. Its schema needs capturing from a live call.- Proof of delivery is not published in any form: no signature image, no POD document URL, no receiver name on delivery. Confirm whether POD is available over API or only in the dashboard.
- Pickup request is not published as a separate call. Confirm whether pickup is implicit on create or an undocumented pickup or manifest route exists.
- NDR action is not published. NDR is readable as a status, but there is no route to reattempt, reschedule or return a shipment sitting in NDR, which is the most valuable write a seller wants there.
- No sandbox: every published request targets production, so test shipments are real bookings. Ask for a test account before integrating. Serviceability likewise has no dedicated route and must be inferred from an empty quote response, and COD remittance has no endpoint, so cash reconciliation stays manual.
- Field name misspellings (
productdetatis,addittional_charges,TOTAL_TAX_AMMOUNT,unauthantication) are reproduced here as published. They are load-bearing: correcting them breaks the call.
Sources
- TekiPost developer API page, read 2026-09-22. Links the Postman collection, states that API keys come from support or the merchant dashboard.
- TEKI POST API V2 Postman collection, fetched as JSON from the Postman documenter API on 2026-09-22. Source of every endpoint, request body, sample response and status vocabulary on this page.
- Live probe of
POST https://app.tekipost.com/api-tracking-details/17127511114046with noAuthorizationheader on 2026-09-22, returning HTTP 200 with{"message":"unauthantication","response":0,"success":false}, confirming the route exists and requires a bearer token. - TekiPost about page, read 2026-09-22. Founded 2022, 8,000 or more sellers, leadership, Tekies Retail Pvt. Ltd.
- TekiPost pricing page, read 2026-09-22. Plan tiers, "Custom Api" gating, COD remittance cadence.