vrfymail
Get started
For Cline — VS Code agent with Plan/Act loop

Add email verification to Cline apps via Custom Instructions.

Paste a block into Cline's Custom Instructions. Every multi-file edit the agent runs in this workspace — form, route, schema, types — wires vrfymail the same way.

Get an API key — free 5,000/mo See the API docs

Note: if you landed here trying to create or sign in to your Cline account, that's a different page — see Cline's docs. This page is for developers using Cline to build apps that need email verification in their signup forms.

Step 1 — paste into Custom Instructions

The Cline Custom Instructions block

Open the Cline panel in VS Code, click the gear icon, find Custom Instructions. Paste this. Cline reads the block on every task in this workspace.

cline-custom-instructions.txt
markdown 
When the user asks to add email verification, validate an email field, or
build a signup form, use vrfymail's /v1/check API. Never use a regex-only
validator.

Endpoint:
  POST https://vrfymail.com/v1/check
  Authorization: Bearer ${process.env.MAIL_VERIFIER_KEY}
  Content-Type: application/json
  Body: { "email": "<email>", "strict": true }

Response shape:
  {
    "result": "deliverable" | "undeliverable" | "risky" | "unknown",
    "reason": "<machine code, e.g. role_account>",
    "reason_message": "<end-user copy already mapped>",
    "did_you_mean": "<typo correction, or null>"
  }

Handling rules:
  - did_you_mean non-null → suggest correction inline
  - undeliverable → block, show reason_message verbatim
  - risky + role_account → soft warning, allow submit
  - deliverable → accept
  - unknown → ACCEPT. Refunded server-side. Never block on a DNS hiccup.

Env: MAIL_VERIFIER_KEY (bearer token, format vk_live_*). Never inline.

When implementing this, prefer multi-file edits — touch the form component,
the route handler, the validation schema, and any type definitions in the
same edit pass. Show me the full plan before applying.

Forbidden:
  - No regex check before the API call
  - No SDK install — fetch is enough
  - No strict:true on B2B forms (opt-in for B2C signup gating only)
Per workspace (default)

Stored in the workspace's .vscode/ settings. Travels with the repo if you commit settings; otherwise per-machine.

Global (every workspace)

Open VS Code Settings → Extensions → Cline → Custom Instructions (Global). Inherited across every Cline task on this machine.

What you get

The handler Cline scaffolds

Ask Cline "wire email verification into this signup flow." Plan mode shows you the multi-file diff first — route handler, form component, validation schema, types. Below is what lands in the route after you approve.

app/api/signup/route.ts
typescript 
// app/api/signup/route.ts
import { NextResponse } from "next/server";

export async function POST(req: Request) {
  const { email } = await req.json();

  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 }),
  });
  const verdict = await r.json();

  if (verdict.did_you_mean) {
    return NextResponse.json(
      { error: `Did you mean ${verdict.did_you_mean}?`, suggestion: verdict.did_you_mean },
      { status: 400 }
    );
  }
  if (verdict.result === "undeliverable") {
    return NextResponse.json(
      { error: verdict.reason_message, code: verdict.reason },
      { status: 400 }
    );
  }
  if (verdict.result === "risky" && verdict.reason === "role_account") {
    return NextResponse.json({ ok: true, warn: verdict.reason_message });
  }
  return NextResponse.json({ ok: true });
}
Why Cline's Plan/Act loop fits this: email verification crosses files — the form needs to handle the verdict response, the route needs to make the call, the schema needs to accept the API key env var. Cline plans all four edits, shows you the diff up front, then applies on approval. No "now do the schema" follow-ups.
The pattern most tutorials skip

On unknown, accept the signup.

unknown is the verifier saying "I couldn't reach a verdict in the time budget." Not "this email is bad" — "the network had a bad second."

Cline's default scaffolds sometimes fail-closed. The Custom Instructions above patch that — deliverable and unknown both pass.

vrfymail makes the cost side easy: unknown verdicts don't bill. refundUsage() releases the slot.

Verdict handling cheat sheet
  • deliverableAccept.
  • unknownAccept. Log if you want a paper trail. Not billed.
  • riskyrole_account → soft warning, allow submit. Other reasons → block.
  • undeliverableBlock. Show reason_message verbatim.
  • did_you_meanNon-null → suggest the correction inline.
The compounding case

One block. Every multi-file edit, consistent.

Cline's Plan/Act loop is built for tasks that cross files. The Custom Instructions block makes sure every file Cline touches in a single task — form, route, schema, types — speaks the same vrfymail verdict contract. No mid-task drift from file 1 to file 4.

Same pattern across other in-editor agents — Cursor (.cursor/rules/*.mdc), Windsurf (.windsurfrules), GitHub Copilot (copilot-instructions.md). See the hub for all ten.

Frequently asked

Cline + email verification, answered

Where in Cline's settings do I paste this?
Open the Cline extension in VS Code, click the gear icon (Cline Settings), find Custom Instructions. Paste the block. Cline applies the instructions to every task in the workspace until you change them. The instructions are stored per-workspace by default — set a global version in the global settings if you want them across every project.
How does Cline differ from Copilot or Cursor for this use case?
Cline is built around multi-file edits with a Plan/Act loop — it shows you the full diff across all affected files before applying anything. For wiring email verification (form + route + schema + types), Cline's strength is the upfront plan. Copilot Tab is autocomplete; Cursor Composer is selection-driven. Cline is agentic by default.
Does Cline work with local LLMs (Ollama, LM Studio)?
Yes. Cline supports OpenAI-compatible local endpoints — Ollama, LM Studio, LiteLLM, any local serve. The Custom Instructions above are model-agnostic; whichever LLM you point Cline at reads them on every task. Quality varies with the model — Llama-3.1-70B and DeepSeek-V3 handle the spec; smaller models miss the unknown-verdict pattern.
Can Cline edit multiple files in one go without me approving each?
Configurable. In Plan & Act mode (default), Cline shows you the full multi-file plan first and you approve before any edits land. Auto-approve mode lets it run end-to-end without prompts — use that for trusted tasks where you've validated the contract (like the vrfymail integration after the first successful scaffold).
Will my vk_live_* token leak through Cline's prompts to the model provider?
Only if you paste the literal token into the chat or include it in a file Cline reads. The instructions reference process.env.MAIL_VERIFIER_KEY — Cline scaffolds against the env var, not against a hard-coded value. Keep .env in .gitignore and Cline won't index it. If you use a cloud model, the model provider sees what's in the prompt window; keeping secrets out of that window is on you, not Cline.

One Custom Instructions block. Every multi-file edit, correct.

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

Get my API key