zerobounce 403 invalid api key bulk verification

TL;DR

The 403 means ZeroBounce rejected the credential, which usually means the key is wrong, revoked, or locked to different IPs. Verify the key in the dashboard, check for IP allowlisting on the account, and send the key exactly as documented. A key that works in the dashboard but 403s from your server is almost always an IP restriction.

zerobounce 403 invalid api key bulk verification

Use this when

• Bulk verification calls return 403.
• The same key works in the ZeroBounce dashboard.
• The integration recently moved servers or IPs.

Not for this skill when

• Single verification works but bulk 403s with a different message. Read the body; it may be a plan limit.
• The error is 429. That is rate limiting.

Steps

1. Copy the key fresh from the dashboard and test with curl from your server. Verify: curl reproduces or clears the 403, isolating client vs credential.
2. Check the account for IP restrictions or allowlists. Verify: your server's egress IP is on the allowed list.
3. Confirm the key is active and not revoked or regenerated. Verify: the dashboard shows the key you are actually sending.
4. Check the egress IP your requests really use (NAT, proxies, and cloud egress can surprise you). Verify: the IP in the request matches the allowlist entry.
5. If the key is active, the IP is allowed, and curl still 403s, contact support with a timestamp. Verify: you have a ticket with evidence.

Variant phrasings

zerobounce 403 api key

The short search, same IP-allowlist diagnosis.

zerobounce invalid key bulk

Endpoint phrasing, points at step 1.

zerobounce key works dashboard not api

Symptom phrasing, lands on step 2.

Compatibility: ZeroBounce API v2. IP restrictions are account-level and easy to forget after infra moves.

Why it happens

API gateways check the credential before anything else, and a 403 (rather than 401) often means the key is recognized but not permitted from this context: wrong IP, wrong product scope, or a revoked key that still looks valid in old config. Infra moves change egress IPs silently, which is why a working integration starts 403ing on a Tuesday with no code changes.

Edge cases / pitfalls

• Cloud egress IPs rotate. An allowlist entry from last year may no longer match.
• Never embed the key in the bulk upload file or filename. Headers only.
• Log key fingerprints (last four chars), never the full key, when debugging.
• A 403 that appears only on bulk but not single verification can be a plan gate. Read the response body before rotating keys.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VaXukcYR6k8PQKM4Vwv4rg