Ad Serving API

Ads in Email

Many publishers discover their most loyal and engaged audiences not only on their websites or apps but also within their email newsletters. In recent years, email-based communities have experienced remarkable growth, presenting a prime monetization opportunity. However, current tools for trafficking, managing, serving, and reporting on email-based advertising fall short. Our API-driven email advertising solution empowers you to deliver enhanced reporting to your advertisers and equip your sales team with sophisticated targeting and selling capabilities, unlocking the full potential of your email audience.

Below is a guide to integrating your email list with the BuySellAds Ad Serving API.

Forming the request

Please refer to the Get Ads Endpoint for making requests. The requests and responses are the same for email based ad serving - the only difference is the values you use for useragent and the optional addition of a hashed email address value. For useragent you will want to pass the string "email" as the value. For forwardedip you will want to pass the users IP that you have detected from a previous interraction with your website, email list, etc. If you do not pass a value for forwardedip the target location for the request will be "unknown" and you will not be able to serve geo-targeted ads for the request.

Hashing Email Addresses

One of the primary use cases for email based advertising is that we can serve ads to specific users based on a hashed version of their email address. This can be a powerful way to increase email CPMs by 10x or more, depending on the use case. Of course, the tradeoff is that the match rate across your list will likely be relatively low with a small set of advertisers. This is why we offer a network based buying solution for advertisers for you to tap into, since it is not always practical or worthwhile to do direct deals with email newsletters to only match a small subset of a list.

Email hash parameter

  • Name

    A concatenated SHA256 hash of the zones Secret Email Hash and the users email address.

Here is what a fully formed request should look like:


curl -G \
  -d useragent=Mozilla%2F5.0%20%28Macintosh%3B%20Intel%20Mac%20OS%20X%2010_15_7%29%20AppleWebKit%2F537.36%20%28KHTML%2C%20like%20Gecko%29%20Chrome%2F94.0.4606.71%20Safari%2F537.36 \
  -d forwardedip=
  -d email_hash=c4d4f98e4b4e8b4cd0b3c0d65984d19dd8f3b3e655039f6b1d6f12e0e81f6c12

To hash an email address, you will first need your zones Secret Hash Key. Login to your BuySellAds account, select the email zone you are integrating, and click to copy the secret hashing key.

Hash the email address

$email = ""; // Replace this with the email address you want to hash
$secret_key = "your-secret-key"; // Replace this with your own secret key

// Check if the email address is valid
if (filter_var($email, FILTER_VALIDATE_EMAIL)) {
    // Concatenate the secret key and the email address
    $email_with_key = $secret_key . $email;

    // Hash the email address with the secret key using the SHA-256 algorithm
    $hashed_email = hash("sha256", $email_with_key);

    // Output the hashed email address
    echo "Hashed Email: " . $hashed_email;
} else {
    echo "Invalid email address";


If you are building and queuing emails on your own and then sending through a 3rd party (such as SendGrid, Nylas, MailGun, and many others) one of your primary considerations will be speed. How much will making a request to the BuySellAds Ad Serving API slow down my send process? The best way for us to address this is to determine whether or not we can locate an ad server in close proximity to there server where you build your emails. Locating two servers in us-east-1 on AWS, 20,000 requests from the test server to our ad server were served in 7.5 seconds (or 0.4ms per request). If you would like help doing a similar experiement, please reach out.

The primary timing issue is network latency. Here are raw (local) serving times for a variety of requests. If we can locate an ad server close to where you generate emails, the question of "how much is this going to slow down our send process?" is "very little".

RequestsParallel ClientsTotal TimeTime per Request
10,000122.6 seconds2.3ms
10,000102.01 seconds0.2ms
100,000507.8 seconds0.1ms
1,000,00020076 seconds0.1ms