What Should Your Sign-Up Form Do When the Verification Call Is Slow or Fails?
A verification check should help your form, never stop it. A short timeout, a clear action for every result and error, and a background re-check keep sign-ups flowing.
A verification call at sign-up is there to help: catch a typo, spot a throwaway address, keep bad data out. It should never be able to stop a real person from signing up. Mail servers are outside your control, networks fail, and keys expire. Plan for that before the first customer meets it.
Two different timeouts
The API documentation suggests a timeout of about 45 seconds for a request, because a slow mail server can take that long to answer. That is the right limit for a background job. It is far too long for a person looking at a form.
- On the page: wait only a few seconds, for example 3 to 5. If the answer has not come, let the person continue.
- In the background: allow the full 45 seconds and store the result when it arrives.
One action for every outcome
| What comes back | What the form does |
|---|---|
| Valid | Accept |
| Invalid | Ask the person to correct the address |
| Typo suggestion present | Show it and let the person accept it |
| Risky | Accept; the mailbox exists but cannot be confirmed |
| Unknown | Accept and mark the address as pending |
| Timeout or network error | Accept and mark the address as pending |
| 422 malformed address | Ask the person to correct it; no credit is charged |
| 429 too many requests | Accept, mark pending, retry later |
| 503 short outage | Accept, mark pending, retry; no credit is charged |
| 401, 402 or 403 | Accept, and alert yourself: this is your key, balance or plan, not the customer's problem |
Only two outcomes ever stop the person: an invalid address and a malformed one. Everything else lets the form go on.
Never show your own problems to customers
A wrong key, an empty balance or a plan without API access are things you need to fix. Do not show the customer a message about them. Log the error with the request id so you can find it later, send yourself an alert, and let the sign-up continue.
Mark, queue, re-check
For every address you accepted without a clear result, store a status such as pending. A background job then asks again after a few minutes, with a limit on the number of attempts. When a result arrives:
- Valid or risky: mark the address verified or unconfirmed and carry on.
- Invalid: do not send marketing mail to it. For an account, ask the person to confirm or correct the address the next time they sign in.
- Still unknown after the attempts: leave it as unconfirmed and let your first send be the test.
Keep the key on the server
Call the API from your back end, not from the browser. A key in page code can be copied by anyone. A short call from your server to ours, followed by a result to your page, keeps the key private.
Keep cost and noise down
- Check an address when it is entered, not on every keystroke.
- Do not re-check the same address in a loop; every checked address uses a credit, also unknown.
- Store the result and the reason with the date, so you never ask twice for the same thing.
A short test plan
Before launch, try five cases: a valid address, an invalid one, a typo, a deliberately wrong key and a pulled network cable. If the form behaves sensibly in all five, you are ready. Start with a few single checks in the email checker to see real results, and read pricing so you know what a check costs.
Frequently asked questions
Should the form wait for unknown results? No. Accept the address and re-check in the background.
What if the API is down? Accept the address, mark it pending and retry. A short outage (503) is not charged.
Can I check the address on the server after submit instead? Yes, and it is often simpler: accept the form, then verify in a background job. You lose the instant typo prompt, so keep a quick page-side check for that.
