Recipient Validation: Email Verification Code Examples. Explore SparkPost

• Data-driven validation, not guesswork. Bird's (formerly SparkPost's) Recipient Validation uses billions of real delivery and engagement events to determine whether an email address is valid, risky, undeliverable, or contains a typo.
• Smarter than syntax checks. Unlike traditional regex-based tools, this model uses real-world data to classify deliverability and even suggests corrections with a "did_you_mean" feature.
• Real-time integration. Validate email addresses directly within your sign-up forms, CRMs, or bulk lists via the /recipient-validation/single/ API endpoint.
• Developer-first examples. Working code snippets are available in multiple programming languages — including Python, Node.js, PHP, Go, C#, Ruby, Java, Rust, and more — to make integration simple.
• Security best practice. API keys should always be stored server-side (never exposed in client-side code), using environment variables such as SPARKPOST_API_KEY.
• Beyond validation. Combine Recipient Validation with webhook consumers or Azure Functions to build scalable, serverless verification workflows for production use.
• Continuous improvement. Developers are encouraged to contribute examples in other languages, ensuring global accessibility across ecosystems.

• What is Recipient Validation?It's Bird's API-powered email validation system that classifies addresses as valid, risky, neutral, undeliverable, or typo, leveraging data from billions of real-world delivery events.

• How does it differ from basic syntax validation?Traditional validators check only format; Bird's system evaluates live data such as bounce rates, engagement metrics, and deliverability patterns to make smarter predictions.

• What kind of information does the API return?Each validation response includes:Status classification (valid, risky, etc.)

• Reason code (why an address is flagged)

• Optional "did_you_mean" correction for typos

• Metadata like pricing, country, and status reason fields

• Can I validate emails in bulk?Yes. You can upload entire lists in the web app or use the API to validate single addresses programmatically as part of your workflow.

• Which programming languages are supported?Code examples are available for more than a dozen languages — including Python, Node.js, PHP, Go, C#, Java, Rust, and Perl — covering both modern and legacy systems.

• Where should I store my API key?Always keep it server-side using an environment variable like SPARKPOST_API_KEY. Never embed it in client-side scripts or browser code.

SparkPost Recipient Validation is now available both for existing SparkPost customers and for new, non-sending customers. It uses powerful data-driven analysis on billions of bounce, delivery, and engagement events daily to train our algorithm, bringing you one of the most powerful data-driven email validation tools on the market, so you can send emails smarter. This represents the latest evolution in email validation techniques, moving beyond simple syntax checks to sophisticated data-driven approaches that provide more accurate results.

This article explains how you can get the most out of the data you'll receive back on each validated recipient – you'll see we classify addresses to be "valid", "risky", "neutral", "undeliverable", and "typo". We give you a "reason" code and also a "did_you_mean" for known address typos.

I'm less familiar with C# – to me, it looks quite Java-like, rather than C-like. I was able to put this together following examples shown in the request library System.Net.Http.

Postman can auto-generate example code using RestSharp, if you prefer that.

In the SparkPost web app, you can drag & drop an entire list for validation. You can also use the API to validate single addresses, so you can build validation right into your address entry workflow.

A while back we came up with a Python command-line tool using this API. We talked over what we should do for other languages – and here we are! Let's get started.

This Github repository folder has working Recipient Validation API call examples in around a dozen different languages. We try to cover the most popular applicable languages.

The common way of working through all these examples is:

• Pick up your key from environment variable SPARKPOST_API_KEY
• Make an API call to /api/v1/recipient-validation/single/to validate a recipient
• Receive back a response string, containing JSON-formatted data with the result
• Print out the result

Language

HTTP library used

Where validation happens

Notable considerations

Bash / Curl

curl CLI

Terminal-only usage

No parsing of response JSON

PHP

curl_setopt

Server-side

Multiple library options available

Python

requests

Script or backend apps

Converts JSON into dict automatically

Node.js

axios (recommended)

Server-side only

Avoid exposing API keys client-side

Go

net/http + encoding/json

Backend services

Strong type safety with custom structs

C#

System.Net.Http

Server applications

Postman can generate RestSharp version

Java

HttpURLConnection

Server services

Verbose but widely deployable

C / C++

libcurl + OpenSSL

Systems-level tooling

Manual memory safety required

Lua

luasocket + luasec

Scripting companion

Can efficiently stream chunked responses

Perl

LWP::UserAgent

Legacy systems

JSON parsing optional

VB.net

Visual Studio SDK

Windows console apps

Environment variable setup required

Rust

reqwest + tokio async

Modern web services

Async needed for header handling

This wins the prize for shortest code – it simply uses the command-line tool "curl" to make the request and print the reply directly to the terminal. You can see the output is a string, containing JSON; we don't actually parse the individual result attributes.

Trusty PHP has a few different ways to make HTTPS API calls. Here, we chose to use curl_setopt together with curl_exec.

If you prefer HTTP_Request2 or pecl_http, then Postman has a built-in code generator that you can use to create similar examples – just set up a working GET request and use the "Code" button.

Postman interface used for API testing, featuring a "Single Address Validation" endpoint with GET parameters, a Headers section showing Authorization and Accept keys, and a highlighted area labeled "Cookies" and "Code" on the right side..

This uses the popular requests module, which is high-level and therefore easy to use. This example checks the returned status code, converts the results JSON back into a Python dictionary object, and prints the resulting object rather than just a string.

If you prefer the built-in http.client library, Postman can generate code for that too; it's not much longer.

There are many different node.js HTTP(S) libraries. I started with the older request package (using a callback function) but it's deprecated and no longer actively maintained. I chose the newer axios package (using promises).

Postman can also give you a Javascript native example and Unirest, in case you prefer those.

Because this code needs access to your API key, we strongly recommend calling our API from your server-side, never from the client (browser / mobile device) side.

Go strives toward a philosophy of "one good way" to do something; in this case, using the built-in "batteries included" libraries net/http, encoding/json and others.

The length is due mostly to the explicit error checking clauses if err != nil {} everywhere (no exceptions LOL).

We also declare the results object structure with field tags, to enable us to "unmarshal" the JSON returned string. We overlay the "results" and "errors" tags to allow for both kinds of return.

I like the speed, type-safety and clarity of Go, even if the code is longer than our previous examples.

I've not written any serious Java before, but it was easy to piece this together by following the general approach used in the SparkPost library for other GET calls.

Incidentally, using VS Code as my editor / debugger worked really well for all the languages here, giving me syntax highlighting, debugger stepping / variables viewing etc. The InputStreamReaderand BufferedReaderconstructs are similar to (and I assume were copied by) Go.

This was a trip down memory lane, as I wrote a lot of C code in the 1990s, some still running deep in telecoms networks somewhere. As the history of C predates the modern Web, it's not surprising that library support is a manual task. We need to download (and compile) a recent version of Libcurl, linking to an OpenSSL library – see the README for actual steps.

This feels like a lot of work compared to modern languages, particularly when Go (or Lua, or Python, or any of the others) are fast enough for tasks like this.

The other thing I had forgotten, despite bearing the scars from previous battles, is the scariness of memory allocation! To keep the example simple, I preallocated the URL string length as 1024 characters, and bounds-checked the email address length (using strlen) before we concatenate into it (using strcat).

We treat the Authorization string with a concatenated API key in the same way .. even though we know a valid API key will never be too long .. that's no protection! User input coming from an environment variable could be anything. You must program defensively.

A more sophisticated developer might use mallocinstead of stack variable allocation, and calculate just how long the joined strings need to be. Having to think about this extra complexity gave me a pain in the diodes down my left side; it reminded me of the risks that C programmers run every day, trying to avoid buffer overruns and unexpected side-effects. Which brings us to ..