For v0 — Vercel's generative UI tool

Add email verification to v0 apps in one prompt.

Paste a single prompt into v0 and it generates a signup form plus the server action that wires vrfymail's API. Export to your Next.js project intact — there's no SDK to install, just a fetch call.

Note: if you landed here trying to fix the v0.app student-email-verification error on your own account, that's a different page — see the Vercel community forum. This page is for developers using v0 to build apps that need email verification in their signup forms.

Step 1 — paste the prompt

The v0 prompt

Open v0, start a new chat, paste this. v0 returns a signup form using shadcn/ui components and a server action that calls vrfymail. You can iterate on the UI without losing the verification logic — the server action is independent.

v0-prompt.txt
markdown
Build a signup form with email verification.

The form has fields: email, password, name. On submit, the form calls a Next.js
server action that verifies the email before creating the account.

Server action: POST to https://vrfymail.com/v1/check with header
  Authorization: Bearer ${process.env.MAIL_VERIFIER_KEY}
and JSON body
  { "email": "<email>", "strict": true }

Response shape:
  - result: "deliverable" | "undeliverable" | "risky" | "unknown"
  - reason: machine code (string)
  - reason_message: end-user copy already mapped (string)
  - did_you_mean: typo correction or null

Handling:
  - did_you_mean non-null → show inline "Did you mean <suggestion>?" with a
    one-click button to apply it.
  - undeliverable → block submit, show reason_message under the field.
  - risky with reason "role_account" → soft yellow warning, allow submit.
  - deliverable or unknown → continue with signup.

Use shadcn/ui Form, Input, Button components. Show validation state inline.
Don't install any SDK — use plain fetch.
Step 2 — env var

In your v0 project, open the Environment tab and add MAIL_VERIFIER_KEY=vk_live_... Redeploy the preview to pick it up.

Step 3 — export

Click Add to codebase to push to GitHub, or download the code and paste into your local Next.js app. No SDK to install — fetch travels intact.

What you get

The server action v0 generates

The form (shadcn/ui Input + Button + Form, with inline validation states) gets generated alongside this server action. The form imports verifyEmail and calls it on submit.

app/actions/verify-email.ts
typescript
// app/actions/verify-email.ts
"use server";

export async function verifyEmail(email: string) {
  const r = await fetch("https://vrfymail.com/v1/check", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.MAIL_VERIFIER_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ email, strict: true }),
    // No cache — verdicts are per-customer and 24h-cached server-side already.
    cache: "no-store",
  });
  const verdict = await r.json() as {
    result: "deliverable" | "undeliverable" | "risky" | "unknown";
    reason: string;
    reason_message: string;
    did_you_mean: string | null;
  };

  if (verdict.did_you_mean) {
    return { ok: false, suggestion: verdict.did_you_mean, error: `Did you mean ${verdict.did_you_mean}?` };
  }
  if (verdict.result === "undeliverable") {
    return { ok: false, error: verdict.reason_message, code: verdict.reason };
  }
  if (verdict.result === "risky" && verdict.reason === "role_account") {
    return { ok: true, warn: verdict.reason_message };
  }
  // deliverable + unknown both pass.
  return { ok: true };
}
Why the prompt structure matters: v0 is excellent at generating UI from a description but inconsistent at deciding whether a call should be server-side or client-side. Specifying "server action" in the prompt anchors the verification call to the server — keeps the bearer token out of the browser bundle and makes the verdict the source of truth.
The pattern most tutorials skip

On unknown, accept the signup.

unknown is what you get when the verification pipeline couldn't reach a verdict in the time budget. DNS lookup failed. MX timed out. None of those are evidence the email is bad — they're evidence the network had a bad second.

v0's default generations sometimes fail-closed (block on anything that isn't deliverable). The prompt above patches that — deliverable and unknown both pass.

On vrfymail the cost-side argument vanishes too: unknown verdicts don't bill. refundUsage() releases the slot when the pipeline can't reach a verdict.

Verdict handling cheat sheet
  • deliverable Accept.
  • unknown Accept. Log the verdict if you want a paper trail. Not billed.
  • risky role_account → soft warning, allow submit. Other reasons → block or quarantine.
  • undeliverable Block. Show reason_message verbatim.
  • did_you_mean Non-null → suggest the correction inline. Works on any verdict.
Why the pair fits

v0 ships forms. vrfymail ships verdicts. Both fit in one fetch.

v0's strength is generating production-shaped React + Next.js code from a description. Its weakness is that "production-shaped" often skips edge cases — fail-closed validation, role-account handling, typo suggestions are easy to miss in a prompt.

vrfymail's response is shaped to be slotted directly into UI: reason_message is end-user copy you can show verbatim, did_you_mean is a one-click correction, role_account as a soft-warning category instead of a hard block. The prompt above gives v0 the shape — the verdict gives v0 the content.

Same pattern works across the other AI coding tools — Cursor via .cursor/rules/email-verify.mdc, Claude Code via CLAUDE.md, and seven more on the AI builders hub.

Frequently asked

v0 + email verification, answered

How do I add the MAIL_VERIFIER_KEY env var in v0?
Open the v0 chat for your project, click the Environment tab in the project settings, add MAIL_VERIFIER_KEY=vk_live_... Then redeploy the preview. The env var is injected at runtime — the generated code references process.env.MAIL_VERIFIER_KEY directly.
Can I export the v0 code into my own Next.js project?
Yes. v0 generates standard Next.js 15 app-router code. Click 'Add to codebase' to push the server action and form into a connected GitHub repo, or download the code and paste it into your project. The vrfymail integration travels intact because there's no SDK — just the fetch call.
Does v0 support running the server action in its preview?
Yes, v0 runs server actions in the hosted preview environment. As long as MAIL_VERIFIER_KEY is set in v0's Environment tab, you can test the full signup flow inside v0 before exporting. The preview hits production vrfymail — call it part of the 5,000/month free tier.
What if I want client-side validation feedback as the user types?
Ask v0 to add a debounced verifyEmail call on the email field's onBlur or after a 500ms typing pause. The server action remains the same; the client just calls it earlier. Most v0 generations will scaffold the debounce + state machine correctly if you specify it in the prompt.
Does this work with v0's Vercel AI SDK integrations too?
Yes. The vrfymail call is independent of any AI SDK v0 wires in. If your generated app uses streamUI or @ai-sdk/* hooks, the verifyEmail server action sits alongside them — it's just a fetch. No conflicts, no shared dependencies.

One prompt. One server action. Real verdicts.

vrfymail's /v1/check returns a verdict in 50ms p50. Free tier: 5,000 verifies/month, no card. Paid plans start at $9/mo for 10,000 — see pricing.

Get my API key