How to Load data from Mandrill to MS SQL Server

This post helps you with loading your data from Mandrill to MS SQL Server. If you are looking to get analytics-ready data without the manual hassle, you can integrate Mandrill to MS SQL Server with RudderStack, so you can focus on what matters, getting value out of your data.

How to Extract my Mandrill’s data?

There are two main methods to get our Mandrill’s data, the first one is to pull data out from it and the second one is to ask Mandrill to push data to us whenever something of importance happens. We will see the difference between these two solutions and how we can have data access from both.

In order to pull data out of Mandrill, we need to access its HTTP API. As a Web API following the RESTful architecture principles, it can be accessed through HTTP. As a RESTful API, interacting with it can be achieved by using tools like CURL or Postman or by using HTTP clients for your favorite language or framework.

A few suggestions:

  • Apache HttpClient for Java
  • Spray-client for Scala
  • Hyper for Rust
  • Ruby rest-client
  • Python http-client

Mandrill maintains a number of officially supported clients or SDKs that you can use with your favorite language to access it without having to mess with the raw underlying HTTP calls.
These are the following:

There are also a number of unofficial clients that you can use if you prefer. The complete list can be found here.

In this post, we will consider the more generic case of accessing the HTTP endpoints directly for our examples, but of course, you are free to use the client of your choice for your project.

Mandrill API Authentication

In order to use the Mandrill API, you first have to generate an API key through your MandrillApp account. When you have created the key, you can use it to access the API.

You can actually have multiple keys per account, something that adds versatility to the platform. In most cases, with the Mandrill API, you make a POST call to access an endpoint with a JSON body containing the access key.

Mandrill rate limiting

API rate limiting with Mandrill is a bit of a more complicated matter than in most cases of APIs out there. The reason is that Mandrill is mainly an SMTP as a service platform, in most cases, when we make a call to its API, we do it in order to send an e-mail to someone, so rate-limiting in the typical sense that we find it in web APIs does not apply in Mandrill.

What is actually happening is that every Mandrill account has a reputation and an hourly quota. The main reason that rate limiting is a bit more complicated in Mandrill is that they need to take special care of pointing out and handling potential spammers.

So the hourly quota is affected by your reputation, if for example, you have a poor reputation then Mandrill will reduce the number of e-mails and consequently the API calls that you can do on a per hour basis, on the contrary, if you have an excellent reputation you will be able to make more calls. Free accounts can send up to 25 emails per hour.

If you want to find your hourly quota and reputation, you will have to check your Dashboard in MandrillApp.

Endpoints and available resources

Mandrill exposes the following endpoints:

  • Users: Information about your account. For example, here, you can validate that your API key is valid.
  • This endpoint is used to send messages through the Mandrill API.
  • Information and operation about user-defined tags.
  • Rejects. Manage your email rejection list.
  • Whitelists. Manage your rejection whitelists.
  • Senders. Manage senders associated with your Mandrill account.
  • Get information about the URLs that are included in your e-mails.
  • Manage e-mail templates.
  • Webhooks. Manage webhooks for your account.
  • Subaccounts. Manage subaccounts.
  • Information about domains that have been configured for inbound delivery.
  • Run export jobs to retrieve data out of your Mandrill account.
  • IPs. Information and operations about your dedicated IPs.
  • Information and operations about your custom metadata fields indexed for the account.

The above endpoints define the complete set of operations that we perform with Mandrill. In our case, we care mainly about what data we can export so we will work with the export endpoint. Export jobs can be executed for the following data:

  • Export your rejection blacklist.
  • Export your rejection whitelist.
  • Export your activity history.

We assume that you would like to export your activity data. In order to do that, you must perform a POST request to the following endpoint:


Keep in mind that the base URL might change depending on the warehouse where your application is hosted. For this reason, we will mention only the endpoints, and you will have to prepend the base URL for your case.

The body that we should post to the above end-point should look like this.

"key": "example key",
"notify_email": "",
"date_from": "2013-01-01 12:53:01",
"date_to": "2013-01-06 13:42:18",
"tags": [
"senders": [
"states": [
"api_keys": [

We must provide our API key, and we can also define a date range from which the API will collect data for. If we want, we can filter even more data we will get back by requesting specific tags or senders and states.

The results will include fields about:

  • Date
  • Email address
  • Sender
  • Subject
  • Status
  • Tags
  • Opens
  • Clicks
  • bounce details

When the export job finishes, data will be available through a URL in a gziped format. Keep in mind that you will have to poll the Exports endpoint to figure out when the job is finished and get the exact URL from which you will get data.

To do that, you should perform a POST request to the following end-point:


The body of the POST request should be a JSON document containing your api-key. You will get back a result like the following:

"id": "2013-01-01 12:20:28.13842",
"created_at": "2013-01-01 12:30:28",
"type": "activity",
"finished_at": "2013-01-01 12:35:52",
"state": "working",
"result_url": ""

Another way of getting data using the Mandrill API is to ask it to push events to our system every time something of importance happens. To do that, we need to set up webhooks on our system and provide the URLs to Mandrill. The platform will POST data in JSON format to these URLs every time an event is triggered. The good thing about this mechanism is that we can have data as soon as possible in our system for analysis.

Every Mandrill webhook uses the same general data format, regardless of the event type. The webhook request is a standard POST request with a single parameter (currently) – mandrill_events.

There are three types of webhooks that Mandrill currently POSTs: Message webhooks (such as when a message is sent, opened, clicked, rejected, deferred, or bounced), Sync webhooks, and Inbound webhooks.

The mandrill_events parameter contains a JSON-encoded array of webhook events, up to a maximum of 1000 events. Each element in the array is a single event, such as an open, click, or blacklist sync event. For examples of each type of event and a description of the keys, select the type of events you’ll be processing:

Message events (send, deferral, hard-bounce, soft-bounce, open, click, spam, unsub, reject)

Sync events (whitelist of blacklist sync)

Inbound messages

For more information about Webhooks, you can check here.

What is Mandrill?

Mandrill is a transactional email API for Mailchimp Users. Although in the past, Mandrill was perceived as a different product than MailChimp, right now it is offered as a MailChimp plugin.

Mandrill is reliable, powerful, and ideal for sending data-driven emails, including targeted and personalized one-to-one messages to your customers.

You might wonder what the differences are between Mandrill and MailChimp, as both of them handle the delivery of emails to your customers. Some key differences between the two are the following:

  • Mandrill is designed for developers. If you are not comfortable with writing code then it would be better if you find someone before you start using it. On the other hand, Mailchimp is designed mainly for marketers, so no technical skills are required to use it.
  • Mandrill focuses more on transactional e-mails, which are different than the promotional/campaign-based emails that marketers send using MailChimp. Transactional e-mails are more tailor-made for cases like one-to-one messages to your customers, like resetting passwords, welcoming them, etc.
  • MailChimp offers richer reporting, but with Mandrill, it is easier to have access to all the raw events related to your e-mails as they happen, so you can run your own analytics if you wish. In general, raw Mandrill’s data are much more accessible than in Mailchimp.
  • If you wish to run complicated campaigns with Mandrill, you will have to implement the logic behind running them. With MailChimp, you can do that using the drag-n-drop environment that it offers.

In general, you can perceive the two services as complementary, MailChimp allows your marketing department to easily and fast execute their marketing strategies, while with Mandrill, you have access to a very flexible and rich environment where you can build complex products on top of e-mail services, but it requires the involvement of your R&D team.

Mandrill, as an email API, exposes all its functionality through it. So apart from being possible to execute a number of operations like sending emails based on specific events, we can also use this API to pull out data or set up our infrastructure in such a way that Mandrill will send to us data over time they are generated.

In this article, we will see in detail the different ways of pulling data out of Mandrill that can be useful for running our analytics.

Mandrill Data Preparation for Microsoft SQL Server

As in every relational database, SQL Server requires a well-defined database schema before we start populating with data. Data is organized in schemas, which are distinct namespaces where database objects belong to.

The most common database objects are of course, tables which have a number of columns, with each one having a declared data type. MS SQL Server supports a large number of different data types, which gives us great flexibility in expressing data that we have and at the same time optimizing our data warehouse.

When working with data coming from web services, where data is usually serialized in JSON, it is important to correctly map data to the right data types. As changing the data types in the future is a process that might cost in downtime of your database, it is important to spend enough time thinking about the proper data type assignments.

For example, dates in JSON are just strings, but when storing date objects in a database, we can enhance analytics with great capabilities by transforming the raw string data into an appropriate date type. A typical strategy for loading data using a source of Mandrill to MS SQL Server database is to create a schema where you will map each API endpoint to a table. Each key inside the Mandrill API endpoint response should be mapped to a column of that table and you should ensure the right conversion to an SQL Server compatible data type.

Of course, you will need to ensure that as the data types from the Mandrill API might change, you will adapt your database tables accordingly. There’s no such thing as automatic data type casting. After you have a complete and well-defined data model or schema for Microsoft SQL Server, you can move forward and start loading your data into the database.

About Microsoft SQL Server

Microsoft SQL Server is one of the oldest and most mature database systems. Its first version was introduced about 28 years ago, in 1989, and Microsoft has been consistently supporting and extending the product until today.

So, it’s no surprise that Microsoft SQL Server has one of the richest feature sets among the currently available database systems.

SQL Server is delivered in different editions or flavors. The most notable is the Enterprise edition, which can manage databases as large as 524 petabytes utilizing up to 12 terabytes of memory and 640 CPU processors. A free and scaled-down version is called Express.

A Business Intelligence version focuses on use cases where BI is performed on-premises. This version is actually a bundle of different products, including the core database system, together with other Microsoft related products than can be used for BI purposes like visualization and data management.

In addition, there are also plenty of specialized versions of the database like the Compact edition that can be used on small devices and, of course, the Azure version, which is the cloud-based edition of SQL Server. Microsoft SQL Server incorporates a modular architecture that can extend the database with additional services. Replication services can extend the database to a cluster version and thus help with scaling and fault tolerance.

The SQL Server Analysis Services, augment the database with OLAP and data mining capabilities, making the database ideal for the workloads that we care about in this guide.

Load data from Mandrill to MS SQL Server

As a feature-rich and mature product, MS SQL Server offers a large and diverse set of methods for loading data into a database. One way of importing data into your database is by using the SQL Server Import and export Wizard. With it and through a visual interface you will be able to bulk load data using a number of data sources that are supported.

You can import data by another SQL Server, from an Oracle database, from Flat Files, from an Access Data Source, PostgreSQL, MySQL and finally Azure Blob Storage. Especially if you are using a managed version of MS SQL Server on Azure, you should definitely consider utilizing the Azure Blob Storage connection.

In this way, you will be loading data as Blobs on Azure, and your MS SQL Server database will sync with it through the Import and Export Wizard.

Another way for importing bulk data into an SQL Server, both on Azure and on-premises, is by using the bcp utility. This is a command-line tool that is built specifically for bulk loading and unloading of data using an MS SQL database.

Finally and for compatibility reasons, especially if you are managing databases from different vendors, you can you BULK INSERT SQL statements.

In a similar way and as it happens with the rest of the databases, you can also use the standard INSERT statements, where you will be adding data row-by-row directly to a table. It is the most basic and straightforward way of adding data into a table but it doesn’t scale very well with larger datasets.

So for bulk datasets, you better consider one of the previous methods.

Updating your Mandrill data on MS SQL Server

As you will be generating more data on Mandrill, you will need to update your older data on an MS SQL Server database. This includes new records together with updates to older records that, for any reason, have been updated on Mandrill.

You will need to periodically check Mandrill for new data and repeat the process that has been described previously while updating your currently available data if needed. Updating an already existing row on a SQL Server table is achieved by creating UPDATE statements.

Another issue that you need to take care of is the identification and removal of any duplicate records on your database. Either because Mandrill does not have a mechanism to identify new and updated records or because of errors on your data pipelines, duplicate records might be introduced to your database.

In general, ensuring the quality of data that is inserted in your database is a big and difficult issue, and MS SQL Server features like TRANSACTIONS can help tremendously, although they do not solve the problem in the general case.

The best way to load data from Mandrill to MS SQL Server

So far, we just scraped the surface of what you can do with MS SQL Server and how to load data into it. Things can get even more complicated if you want to integrate data coming from different sources.

Are you striving to achieve results right now?

Instead of writing, hosting, and maintaining a flexible data infrastructure, use RudderStack that can handle everything automatically for you.

RudderStack, with one click, integrates with sources or services, creates analytics-ready data, and syncs your Mandrill to MS SQL Server right away.

Sign Up For Free And Start Sending Data

Test out our event stream, ELT, and reverse-ETL pipelines. Use our HTTP source to send data in less than 5 minutes, or install one of our 12 SDKs in your website or app.

Get Started Image

Get started today

Start building smarter customer data pipelines today with RudderStack. Our solutions engineering team is here to help.