PostalPinCode

Gotchas & limits

• The live response wraps the whole envelope in a one-element JSON array — [{"Message":...,"Status":...,"PostOffice":[...]}] — even though the API's own docs page (postalpincode.in/Api-Details) shows the identical fields as a bare object with no wrapping array. Code that expects the documented shape needs to index [0] first (confirmed live this run against both /pincode and /postoffice).
• Nothing ever fails with a non-2xx HTTP status — branch on the body, never on the transport code. Both a well-formed but unassigned 6-digit PIN (GET /pincode/999999) and a malformed non-numeric segment (GET /pincode/abcdef) return HTTP 200; only the body shape differs. The former gives the docs' own documented error envelope, [{"Message":"No records found","Status":"Error","PostOffice":null}]; the latter gives an undocumented one with no PostOffice key at all — [{"Status":"404","Message":"The requested resource is not found","RequestUri":"https://api.postalpincode.in:443/pincode/abcdef"}], where that 404 is a string inside the JSON, not the HTTP status. /pincode/12, /pincode/1100011 and a bare /pincode/ are all HTTP 200 too (all measured live this run; a control request through the same egress path did return a real HTTP 404, so this is the API's behaviour and not a proxy artifact).
• Plain http:// is hard-blocked rather than redirected: a live GET http://api.postalpincode.in/pincode/682001 returned HTTP 403 Forbidden with no Location header — callers must use https:// from the very first request (confirmed live this run).
• The second documented endpoint, GET /postoffice/{branchName}, matches on post-office branch name rather than PIN — so it's the one that discovers a PIN you don't already know, where /pincode/{pin} requires you to supply it up front. A live GET /postoffice/New%20Delhi returned 2 matches whose Name values are New Delhi (note the trailing space, and no G.P.O. suffix — that word only shows up in its Division, New Delhi GPO) and New Delhi South Ext-II, carrying Pincode 110001 and 110049 respectively. Its Message also reads Number of Post office(s) found:2 here, while the /pincode lookup words the same field Number of pincode(s) found:1 — don't parse either string.
• access-control-allow-origin: * is returned only when the request actually carries an Origin header — a live GET sent without one came back with no CORS header at all, while the same GET plus Origin echoed * on both the success and the error probe above. A live OPTIONS preflight to the same path returned no CORS headers either, just a plain Allow/Public method list. In practice that's fine, because a browser always sends Origin on a cross-origin request: safe to call from browser JS as long as it stays a simple GET with no custom headers that would force a preflight.