Response Codes
Every application-level code Ziptax can return, what it means, and how to handle it
Every application-level code Ziptax can return, what it means, and how to handle it
Every Ziptax response carries an application-level response code in addition to the HTTP status. The code tells you what happened in business terms (success, bad input, plan-gated feature, quota exhausted, and so on) and is the signal your integration should branch on.
Both success and error responses use the same envelope. The code lives
at metadata.response:
Legacy versions (v50 and earlier) return the same fields at the top
level as rCode, rName, and rMessage instead of nested under
metadata.response. The numeric codes are identical across all
versions.
The lookup completed and the response contains rate data. Always check
for 100 before reading baseRates or taxSummaries.
The X-API-Key header (or key= query parameter) is missing,
malformed, or doesn’t match a key in our database. Check for trailing
whitespace, encoding issues, or using the wrong environment’s key.
The state, city, postal code, or overall query string isn’t in a shape Ziptax can parse. These are deterministic, so re-sending the same request will always fail the same way. Fix the input before retrying.
Something went wrong on our end. Safe to retry with exponential backoff. If you see these persistently, email support@zip.tax.
The API version or feature you requested isn’t available on your plan
(for example, calling /request/v60 on a plan that only includes v40).
Upgrade your plan or use a supported version.
You’ve sent more requests than your per-minute request_rate
entitlement allows within the current 60-second sliding window. The
response includes X-RateLimit-Limit and X-RateLimit-Remaining
headers. See Rate Limiting & Errors for
backoff guidance.
The address (or lat/lng, or postal code) you sent couldn’t be resolved to a real location. Common causes: missing street number, obviously wrong ZIP for the city, coordinates in the middle of the ocean, or a typo that leaves the geocoder unable to disambiguate.
Parameters were valid but nothing matched. Most common on historical lookups where the date precedes our coverage, or niche international territories.
The historical parameter wasn’t accepted. Use the format YYYYMM
(6 digits, no separator, e.g. 202401 for January 2024). The API also
rejects the current month, any future month, and months older than the
service’s historical coverage window.
You passed countryCode=CAN (or another non-USA country) but your
account doesn’t have the rate_loc_can entitlement. Upgrade to Pro or
Enterprise to unlock Canadian lookups.
You passed taxabilityCode=... but your account doesn’t have the
product_rates entitlement. Upgrade to Pro or Enterprise to unlock
product-specific rate rules. See Taxability Information Codes
for what this parameter does.
Branch on the numeric code, not the HTTP status or message text. The
messages are documented here for humans but may be refined over time.
The codes are stable.