535 Error with Expired Token in API

Q: What does a 535 error mean in email verification APIs?

The 535 error means authentication failed. It typically occurs when the API token has expired or is invalid, not when the email address is wrong.

Q: Can expired tokens cause 535 errors during bulk verification?

Yes. If the token expires during a bulk verification with rate limiting, the next call fails with 535 unless the token is refreshed before the delayed call.

Q: Does Emaillistchecker.io auto-refresh expired API tokens?

No. Tokens are not auto-refreshed. The client application must manage token renewal before expiry, especially during long runs or rate-limit pauses.

Q: How long are Emaillistchecker.io API tokens valid?

Tokens are valid for 60 minutes. This matches standard industry practices for secure API access.

Q: Why do I only see 535 errors during rate-limited calls?

Rate limiting introduces delays. If a delay exceeds the token’s 60-minute lifetime, the next request fails with 535—timing is the trigger, not the list quality.

Q: Is a 535 error the same as a bounce?

No. A 535 error is authentication-related. Bounces are delivery outcomes like 'user unknown' or 'mailbox full'.

Q: Can I use a long-lived token with Emaillistchecker.io?

Technically possible, but not supported. Our system uses short-lived tokens for security. Long-lived tokens are not issued or accepted.

Q: How can I detect if a 535 error is due to token expiry?

Correlate the error timestamp with token creation time. If the call was made more than 60 minutes after token generation, expiry is likely the cause.

Q: Does Emaillistchecker.io support API call retries for 535 responses?

The API response does not include retry logic. Clients must implement retries after refreshing the token or handling the error.

Q: What’s the best way to avoid 535 errors in high-volume workflows?

Refresh tokens before expiry—ideally at 75% of lifetime—and use exponential backoff with active token validation during pauses.

What Causes the 535 Error in Email Verification APIs During Rate-Limited Calls?

You’re sending bulk email verification requests, everything’s running smoothly—then suddenly, a 535 error appears. You didn’t change anything. The API was working fine just seconds ago. What broke, and why does it happen specifically when rate limits kick in?

The 535 error isn’t about invalid syntax or malformed addresses. It’s an SMTP-level signal: 535 Authentication failed. It means the system tried to authenticate with the email provider’s server, but the credentials—usually a token—were no longer valid. The real issue? Token expiration timing in the middle of a rate-limited call sequence.

Rate limiting doesn’t just slow things down; it creates delays between API calls. If your system doesn’t refresh the authentication token before the next request goes out, and the token expired during that pause, the server rejects it. The 535 error is the symptom—not the cause.

Key takeaways

535 errors during rate-limited calls indicate expired authentication tokens, not invalid email syntax.
Delays caused by rate limiting create windows where tokens expire before the next API request, leading to authentication failure.
Robust verification systems must automatically refresh tokens before the next call, especially after delays, to avoid 535 responses.

How Does Token Expiry Interact with API Rate Limiting in Email Validation?

When your email verification API hits a 535 error during rate-limited calls, it’s usually because the authentication token expired before the next call was made—and rate limiting delayed retries beyond the token’s lifespan. This traps you in a cycle: the call fails, you retry, but the token is no longer valid, and the server rejects it with a 535 SMTP error. It's a common but preventable issue when token management and rate limits aren’t aligned.

Token Expiry and Rate Limiting: A Timing Mismatch

Most email verification APIs, including Emaillistchecker.io, use short-lived tokens for security and access control. These tokens are typically valid for 15 to 60 minutes. If you’re making bulk calls and the API enforces rate limits (say, one call every 10 seconds), a long verification batch can take several minutes—easily exceeding token validity.

When the token expires mid-batch, any subsequent call using the old token gets rejected with a 535 error: "Authentication credentials invalid." Even if the request body is perfectly formed, the server won’t process it because the session is no longer authenticated. This isn’t a data issue—it’s a timing and flow issue.

Proactive Management to Avoid 535 Errors

Let’s break this down: rate limiting stretches out your call schedule, and if your tokens expire before the next call, you’ll keep getting 535 errors. The fix isn’t to increase the token lifespan (which reduces security) but to renew the token before it expires—especially in long-running processes.

Use a token refresh strategy: track when the current token will expire and initiate a new token request before it lapses. If you’re building your own verification pipeline, ensure your client code checks token validity before each call and renews silently when needed. Many APIs, including Emaillistchecker.io’s verification API, support this pattern. You can integrate it seamlessly through scheduled renewals or by using the token refresh endpoint when available.

For bulk verification workflows, consider using our bulk verification tool — it automates token refreshes and rate management so you don’t have to. This reduces the risk of 535 errors from token expiry during long processes.

For deeper insight into SMTP error codes, refer to the official SMTP specification (RFC 5321), which defines 535 as an authentication failure. The error is not about the email address—it’s about identity. This makes token expiry and refresh timing critical in any automated email validation system.

Why 535 Is Not a List Quality Issue — It’s an Authentication Timing Problem

When your email verification API returns a 535 error during rate-limited calls, it’s not because of bad email addresses—it’s because the authentication token expired while the system was waiting to retry due to throttling. This is a timing issue in your integration, not a problem with the email list itself. The 535 error comes from the API’s authentication layer, not the email validation engine.

The 535 Error Is Not a Verification Result

Unlike a 550 (invalid email) or a 551 (user unknown), a 535 error means the server rejected your request because the credentials were no longer valid. It’s a failure at the access layer, not the delivery layer. The underlying email might be perfectly valid—it just can’t be checked because the auth token expired before the call completed.

This often happens when your API client doesn’t refresh the token in time. If your system hits rate limits, the retry loop might delay the request past the token’s expiry window. A retry policy that doesn’t account for token lifetimes will fail even on perfectly good emails. You’re not checking bad data—you’re hitting a timing gap in your own code.

How to Prevent 535 Errors in Your Integration

Let’s be clear: 535 errors don’t reflect list quality. They reflect implementation logic. The fix isn’t to scrub your list—it’s to manage authentication state in your code. Make sure the token refresh happens before the rate-limited retry queue kicks in.

Best practice: always refresh the token at least 10–15% before expiry. If your token lasts 1 hour, refresh every 50–55 minutes. Also, avoid retrying failed calls without checking if the auth state is still valid. A delay of 30 seconds due to rate limiting can be fatal if the token expired 15 seconds ago.

For more on how API authentication works in real-world systems, see the RFC 5322 specification for email addressing and authentication flows, or explore how providers like Mailgun and SendGrid handle session renewal under load (see Mailgun’s documentation and SendGrid’s guides).

If you’re building or maintaining an API integration, verify your auth flow with real-world load testing. Tools like Postman and built-in rate-limiter simulators can help spot these timing issues early. For a seamless, scalable verification stack, try our real-time verification API, which handles token lifecycle management and rate control behind the scenes—so you don’t have to.

Real-World Example: Token Expire During a Rate-Limited Bulk Verification

You get a 535 error during a bulk API verification because your authentication token expired while waiting for rate limit reset. Your system sent 950 calls in under an hour, hit the 1,000/hr cap, paused for 36 seconds — but your token, valid for one hour, expired after 59 minutes. The next call failed with 535: authentication required. The API didn’t retry or refresh the token automatically. This isn’t a flaw in Emaillistchecker.io’s service, but a gap in how your system handles token lifecycle during throttling.

How the Failure Process Unfolds

Start verification with a valid token. You begin sending 500 email checks via Emaillistchecker.io’s verification API, using a token valid for 60 minutes.
Hit rate limit after 950 calls. At call 950, you’ve reached 95% of your 1,000 calls per hour. The API returns a 429 status code and instructs you to wait 36 seconds before retrying.
Token expires during pause. The 36-second wait period exceeds your token’s 59-minute lifespan. When you retry after sleep, the request arrives with an expired token — the API cannot authenticate it.
Receive 535 error with no retry logic. The server responds with HTTP 535 — “Invalid or expired token” — which your client may not handle. Without automatic refresh, the job fails silently.
Result: 500 failed verifications, no recovery. You end up with a partially verified list and no way to resume without a new token, increasing retry burden and potential for data drift.

Solutions to Prevent It

Rate-limiting is standard. RFC 6585 defines HTTP 429 as the correct response to excessive requests — Emaillistchecker.io follows this. But token lifetime must align with operational window. Here’s how to fix it:

Use short-lived tokens with automatic refresh logic. Never rely on a token lasting longer than your expected process window.
Check token expiration in your code before every API call. If expires_in is near threshold (e.g., < 5 minutes), refresh it proactively.
Implement exponential backoff and retry with token refresh on 429 or 535 errors — this is common in robust integration patterns.
Break large jobs into smaller groups (e.g., 500 per batch) and ensure each batch completes within token validity.

A well-designed system doesn’t just call an API — it monitors its own state. Bulk verification tools handle rate limits internally, but when you're coding your own flow, you’re responsible for state awareness. The 535 error isn’t a server issue — it’s a signal your client didn’t manage the token lifecycle.

Authentication tokens aren’t just credentials — they’re time-bound gates. When rate limits pause your flow, they can open the gate on the wrong side.

The Difference Between 535 Errors and Standard Verification Verdicts

If your email verification API returns a 535 error during rate-limited calls, it’s not a problem with the email address—it’s a failure in authentication. The 535 error means your API token is expired or invalid, not that the recipient doesn’t exist. Standard verdicts like 550 (nonexistent), 551 (user unknown), or 554 (rejected) are delivered by the recipient’s mail server after authentication succeeds. The 535 error stops the process before it even reaches the mail server.

SMTP Response Codes: What They Really Mean

Understanding SMTP error codes is essential when debugging verification results. Here’s how they differ in practice:

Code	Meaning	Trigger Condition	Common Cause
535	Authentication failure	API token or credentials rejected	Expired or invalid token, incorrect API key, or missing credentials
550	Recipient does not exist	Mail server confirms address is invalid	Typo in email, fake or deleted account
551	User unknown	Server rejects delivery due to missing account	Domain exists but user does not; often a catch-all false positive
554	Message rejected	Filtering rules block the message	Spam content, blacklisted sender, or strict inbound policies
451	Temporary server failure	Server can’t process request now	Overloaded server, greylisting, or transient network issue

These codes originate from the Simple Mail Transfer Protocol (SMTP), defined in RFC 5321. The 535 error specifically indicates a failure at the initial handshake—before any address validation occurs. If you’re hitting 535 errors during rate-limited requests, your API credentials are likely invalid or have expired.

Let’s say you’re using a rate-limited API. Even with a valid token, if it expires during a burst of requests, the authentication step fails on retry, returning 535 instead of progressing to address checks. The fix is not to retry more—it’s to ensure your token stays valid and refreshes reliably.

To avoid this, integrate token refresh logic or use an API that manages sessions for you. For example, our real-time verification API includes handling for common edge cases like rate limits and token expiry, so you don’t have to build it yourself. You can also perform bulk verification with our bulk tool if you’re processing large datasets consistently.

Preventing 535 Errors: Best Practices for Rate-Limited API Usage

535 errors during API calls typically occur when authentication tokens expire mid-request, especially under strict rate limits. To avoid this, you must proactively manage token lifetimes, refresh tokens before they expire, and build retry logic that checks for token validity during backoff delays. It’s not just about avoiding failures—it’s about maintaining consistent deliverability at scale.

Token Management Fundamentals

Always refresh authentication tokens before they reach their expiration deadline—never wait until they’ve expired.
Choose token lifetimes that comfortably exceed your expected call intervals, especially when rate limits are enforced tightly or your system makes high-frequency requests.
Use token expiration timestamps to schedule renewal at 75% of the token’s total lifetime. This gives you buffer time to renew without risk of timeout.

Resilience Through Retry Logic

Implement exponential backoff during rate-limited responses, but pause to check if the current token is still valid before retrying.
During backoff delays, treat the interval as a window to renew the token—don’t assume it remains valid until the next call.
Monitor authentication token expiry times in real time. Tools like EmailListChecker’s API provide accurate verification at scale while handling rate limits robustly.

Rate-limiting systems are designed to prevent abuse, but they’re also unforgiving when authentication fails in the middle of a sequence. A single 535 error can delay a whole verification batch. The fix isn’t just about retrying—it’s about anticipating failure modes.

According to industry best practices published by the IETF’s OAuth specification, token management should be stateful and proactive, not reactive. That means tracking expirations, planning renewals, and validating access before making requests. It’s not optional.

“Proactive token renewal is not a convenience—it’s a necessity for reliable API integration under rate limits.”

When your system makes hundreds of calls per minute, a 535 error isn’t just a hiccup—it’s a cascading failure. By managing tokens early and validating them before use, you maintain steady throughput and avoid unnecessary delays. You’re not just avoiding errors—you’re building resilience into every layer of the process.

How Emaillistchecker.io Handles Token Expiry in Rate-Limited Contexts

When your Email Verification API hits a 535 error due to an expired token during rate-limited calls, it means the authentication token has expired after its 60-minute lifetime—our system does not auto-refresh tokens. This is by design: you handle refresh logic, and the 535 error explicitly signals the issue is on your end, not ours. Our bulk verification workflows are built to resume reliably even if tokens expire mid-run.

Stateless Tokens, Fixed Lifetime

Our API uses stateless JWTs with a strict 60-minute expiry, which aligns with industry-standard practices for secure, scalable API designs. This approach avoids server-side session tracking, improving performance and consistency. You’ll find similar lifetimes in RFC 7519 (JSON Web Token spec), which defines the standard framework for token-based authentication.

Explicit Failure, Not Auto-Retry

We return a 535 error code when a request arrives with an expired or invalid token to make failure conditions unambiguous. This is not a temporary network hiccup—this is a clear signal: your authentication layer needs updating. Unlike systems that silently retry or retry with cached tokens, we do not attempt to auto-refresh or reuse expired credentials. This prevents misdiagnosis of delivery issues and keeps your integration robust against state drift.

Let’s be clear: if you’re hitting 535 during long bulk runs, the root cause isn't our API misbehavior, but rather that your token management strategy doesn’t account for the 60-minute window. Long-running verification jobs should either refresh the token before it expires or split the dataset into smaller, time-bound batches.

Our bulk verification system on Emaillistchecker.io is resilient to interruptions, including token expiry. It tracks progress, resumes from the last successful batch, and logs errors—so you don’t lose work. Whether you're verifying 500 or 50,000 emails, the system handles transient failures, including stale tokens, without halting execution.

To avoid the 535 error in practice, set up a token refresh loop that renews your credential at least every 50 minutes. This ensures uptime during rate-limited runs and keeps your verification pipeline running smoothly. You’re in control, and we make it easy to see where failures originate.

What to Do When You Get a 535 Error After 24 Hours of API Inactivity

If your email verification API returns a 535 error after 24 hours of inactivity, the likely cause is a token that expired during the idle period. Token expiration is common with short-lived auth tokens—especially if your system doesn’t refresh them automatically. You need to validate token status before each API call and avoid long gaps between requests. Let’s fix that.

Check Your Token Creation Process

Ensure your token generation process does not produce long-lived tokens that expire mid-verification. Long-lived tokens increase risk of mid-process failure.
Use standard OAuth 2.0 practices: request a new token only when the previous one fails, not on a fixed schedule. This avoids unnecessary refreshes.
Review the documentation of your identity provider (e.g., Auth0, AWS Cognito, or your email service) to confirm acceptable token lifetimes. Some services issue tokens with a 24-hour expiry window.

Review Your API Call Schedule & Use Reliable Token Management

Long delays between API calls increase the chance a token expires before the next request. Avoid batching calls with large gaps—for example, don’t queue 500 verifications with a 24-hour delay between batches.
Store tokens persistently but check their expiry time before each call. Never assume a token is still valid after an extended idle period.
Log every API response with a timestamp. Correlate 535 errors with the age of the token during the call. This helps confirm whether expiry was the root cause.
Use an HTTP interceptor or wrapper function to automatically check token validity. If expired, refresh it before retrying the request. This reduces manual oversight.
Consider using a short-lived token with automatic renewal via refresh token if your provider supports it. This is an industry-standard approach for maintaining uninterrupted access.

Token expiration is a common source of 535 errors in rate-limited environments. The key is not to treat it as a failure of the verification system, but as a predictable outcome of short-lived auth mechanisms.

For teams managing bulk email verification, automated token handling is essential. If you're using a third-party API like EmailListChecker’s, you can reduce friction by using our dedicated verification API, which handles authentication and retry logic for you. It also includes built-in safeguards against common issues like expired tokens and throttling.

Understanding token lifecycle and integrating validation into your call pipeline is the most effective way to prevent 535 errors during extended inactivity. Always validate before you send—don’t assume anything.

Why Not Rely on Long-Lasting Tokens? The Trade-Offs

Long-lived tokens reduce management overhead but dramatically increase risk if they’re stolen or leaked. A token that never expires gives attackers indefinite access to your API, which could result in abuse, data exfiltration, or unauthorized verification runs. That’s why systems like Emaillistchecker.io enforce short-lived tokens—even in high-volume environments—to minimize exposure during security incidents.

The Security Cost of Staying Active

Think of a long-lived token like a master key left under a mat. Sure, you don’t have to replace it often, but if someone finds it, they can unlock everything indefinitely. With short-lived tokens, even if a token is compromised, it becomes useless after its brief window—usually seconds to minutes.

Revoking a long-lived token requires manual intervention and often involves reissuing access across multiple systems. This delay can lead to prolonged abuse during a breach. Short-lived tokens automatically expire, reducing the window of impact and aligning with industry best practices like those outlined in RFC 6749 on OAuth 2.0, which treats token expiry as a core security mechanism.

What This Means for Your API Integration

You lose some convenience—short tokens mean you have to manage renewal cycles, refresh logic, and session stability. But this is the industry standard for good reason. Services built for scale, like Emaillistchecker.io’s real-time verification API, are designed with this in mind. We’ve optimized the token handshake to happen quickly and reliably, so you get security without sacrificing performance.

With short tokens, even if your app hits a rate-limited state, the worst-case scenario is temporary access failure—not an open door to your system. This is especially important when you’re processing thousands of addresses via bulk verification—security can’t be an afterthought.

At Emaillistchecker.io, we prioritize defense-in-depth. Short token expiry is one of the foundational layers. It means you can push data safely at scale, knowing that access isn’t perpetually open. The trade-off isn’t hard to manage—it’s built into the system. You handle the logic; the provider handles the risk.

How to Validate Token Management in Your Integration Layer

If your email verification API hits a 535 error during rate-limited calls, it’s likely because the token expired mid-request. You need to check token validity before each call, refresh tokens proactively (within 10 minutes of expiry), log errors with token timestamps, and alert on failure rates above 1% to catch depletion before it impacts deliverability.

Proactive Token Handling

Check token validity before every API call. Don’t assume a token remains valid. A 535 error after a rate limit window often means the token expired during a burst of requests. Add a runtime check against the token’s expiration time before dispatching any request.
Use middleware to auto-refresh tokens 10 minutes before expiry. Let’s say your API token lasts 60 minutes. Refresh it at the 50-minute mark. This prevents race conditions and ensures uninterrupted calls during high-volume bursts. Tools like Email List Checker’s real-time verification API expect consistent access — missing even one request can skew validation results.
Log 535 responses with the token's creation time and duration. Not just the error, but when it happened and how long the token was active. This helps trace whether the issue is expiration, rate limiting, or misconfiguration. Keep this data in an audit log for later review.
Set up alerts when 535 errors exceed 1% of total calls. A sustained 1% error rate signals a deeper problem. Use your observability stack (e.g., Datadog, Sentry) to monitor this. If 535s spike, it may indicate token rotation failure or an uncaught refresh timeout. Address early to avoid delivery drops.

Why This Matters

SMTP servers return 535 for failed authentication — not just expired tokens, but also invalid or revoked ones. If your system doesn’t handle expiry cleanly, you risk failing calls during critical windows, especially with high-volume tools. For example, RFC 5321 strictly defines 535 as "authentication credentials rejected," making it a key indicator for integration health.

Many teams overlook this layer. They monitor total calls and success rates but skip validation of the underlying auth state. Yet, even a single expired token during a bulk verification can leave a portion of a list unverified — and you won’t know unless you log these errors. With bulk email verification, such gaps translate directly to wasted campaigns and poor inbox placement.

Final Takeaway: 535 Is a Signal, Not a Dead End

A 535 error during rate-limited calls indicates a timing or authentication issue, not a problem with your email data. The error occurs when the API token has expired, and the request is rejected before it can process.

Fix the Flow, Not the Data

Track the age of your API token and refresh it before expiry.
Implement retry logic with updated credentials to maintain uninterrupted verification.
Rate-limiting is a system-level safeguard—auth must be managed within the flow.

High-accuracy tools like Emaillistchecker.io deliver consistent results only when integration logic handles token lifecycle correctly. Without proper auth management, even a 98.9% accurate system can fail in production.

Keep reading

Ready to put this into practice? Emaillistchecker.io verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What does a 535 error mean in email verification APIs?