How does the API key prefix identify Valid Email Checker keys?

Every API key issued by Valid Email Checker is recognizable on sight because the first three characters are always the same: capital VEC. The prefix sits at the start of every key with no separator — no underscore, no hyphen, no dot. Right after VEC you get 32 random characters, for a total fixed length of 35.

Why a fixed prefix

Prefixed keys are an industry pattern (Stripe uses sk_live_ / sk_test_, GitHub uses ghp_, OpenAI uses sk-) because they make accidental leakage easier to catch. Secret scanners on GitHub, GitLab, and most security tooling watch for known prefixes and alert when a string with the right shape lands in a public commit. By using a recognizable VEC prefix instead of pure randomness, our keys plug into that ecosystem automatically.

It also lets you triage a strange-looking string at a glance: paste it into a chat, look at the first three letters, and you know whether it is a Valid Email Checker key or something else.

The exact format

The random body draws from a curated alphabet that deliberately excludes confusable characters. Uppercase O, lowercase o, capital I, lowercase i, lowercase l, the digit 0, and the digit 1 are all banned. The remaining set is ABCDEFGHJKLMNPQRSTUVWXYZ plus abcdefghjkmnpqrstuvwxyz plus 23456789 — 55 characters total. That means a key can safely be read aloud over the phone or typed by hand without ambiguity.

How to validate a key in your own code

A cheap client-side sanity check before you send a key to the Valid Email Checker API:

function looksLikeVecKey(s) {
  if (typeof s !== 'string') return false;
  if (s.length !== 35) return false;
  if (!s.startsWith('VEC')) return false;
  // Body must be 32 chars from the confusable-free alphabet
  return /^VEC[A-HJ-NP-Za-hj-km-np-z2-9]{32}$/.test(s);
}

Run that before making any API request and you catch fat-fingered copy-paste mistakes before they become network round trips. The server will reject malformed keys with 401 Invalid or inactive API key regardless, but the local check is faster and saves credits on rate-limit accounting.

Prefix vs full key in logs

The Developer page only shows the masked form VECabc... in the table. The full key is shown exactly once at creation time and never recoverable afterward — we store keys as a SHA-256 hash on the server side, so even our database does not contain the plaintext. That is also why log scrubbers are safe to write against the VEC prefix: anything you find in a log that matches VEC[A-Za-z0-9]{32} should be redacted immediately because nothing else on the platform shares that shape.

Next steps