How to Extract my data from Mandrill

There are two main methods to get our data from Mandrill, 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 access data from both.

In order to pull data from 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:

• Ruby
• Python
• NodeJS
• PHP
• JavaScript

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 from 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 need to perform a POST request to the following endpoint:

JSON
Copy
/exports/activity.json

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.

JSON
Copy
{
   "key": "example key",
   "notify_email": "notify_email@example.com",
   "date_from": "2013-01-01 12:53:01",
   "date_to": "2013-01-06 13:42:18",
   "tags": [
       "example-tag"
   ],
   "senders": [
       "test@example.com"
   ],
   "states": [
       "sent"
   ],
   "api_keys": [
       "ONzNrsmbtNXoIKyfPmjnig"
   ]
}

We need to 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 the 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, the 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 the data.

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

JAVASCRIPT
Copy
/exports/info.json

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

JAVASCRIPT
Copy
{
   "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": "http://exports.mandrillapp.com/example/export.zip"
}

As you can see from the response, we get a URL from which we can fetch the data and information about the completion or not of the job, if the state of the job is “complete” then we can safely download the data and further process it.

Another way of getting data from 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 the 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.

Mandrill Data Preparation for Snowflake

The first step, before you start ingesting your data into a Snowflake data warehouse instance, is to have a well-defined schema of your data.

Data in Snowflake is organized around tables with a well-defined set of columns with each one having a specific data type.

Snowflake supports a rich set of data types. It is worth mentioning that a number of semi-structured data types is also supported. With Snowflake, it is possible to load directly data in JSON, Avro, ORC, Parquet, or XML format. Hierarchical data is treated as a first-class citizen, similar to what Google BigQuery offers.

There is also one notable common data type that is not supported by Snowflake. LOB or large object data type is not supported, instead, you should use a BINARY or VARCHAR type instead. But these types are not that useful for data warehouse use cases.

A typical strategy for loading data from Mandrill to Snowflake 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 a Snowflake 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 Snowflake, you can move forward and start loading your data into the database.

Load data from Mandrill to Snowflake

Usually, data is loaded into Snowflake in a bulk way, using the COPY INTO command. Files containing the data, usually in JSON format, are stored in a local file system or in Amazon S3 buckets. Then a COPY INTO command is invoked on the Snowflake instance, and data is copied into the data warehouse.

The files can be pushed into Snowflake using the PUT command into a staging environment before the COPY command is invoked.

Another alternative is to upload the data directly into a service like Amazon S3, from where Snowflake can access the data directly.

Finally, Snowflake offers a web interface as a data loading wizard where someone can visually set up and copy the data into the data warehouse. Keep in mind that this wizard’s functionality. Just keep in mind that the functionality of this wizard is limited compared to the rest of the methods.

Snowflake in contrast to other technologies like Redshift, does not require a data schema to be packed together with the data that will be copied. Instead, the schema is part of the query that will copy the data into the data warehouse. This simplifies the data loading process and offers more flexibility on datatype management.

Updating your Mandrill data on Snowflake

As you will be generating more data on Mandrill, you will need to update your older data on Snowflake. This includes new records and updates to older records that or any reason have been updated on Mandrill for any reason.

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 Snowflake table is achieved by creating UPDATE statements.

Snowflake has a great tutorial on the different ways of handling updates, especially using primary keys.

Another issue that you need to take care of is identifying and removing 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 the data that is inserted in your database is a big and difficult issue.

The best way to load data from Mandrill to Snowflake and possible alternatives

So far we just scraped the surface of what can be done with Snowflake and how to load data into it. The way to proceed relies heavily on the data you want to load, from which service they are coming from, and your use case requirements.

Things can get even more complicated if you want to integrate data coming from different sources. A possible alternative, instead of writing, hosting and maintaining a flexible data infrastructure, is to use a product like RudderStack that can handle this kind of problems automatically for you.

RudderStack integrates with multiple sources or services like databases, CRM, email campaigns, analytics and more. Quickly and safely move all your data from Mandrill to Snowflake and start generating insights from your data.