Messages API enhancements & inbound wildcard domains

The Postmark Messages API has always been a robust way to view the archive of messages you’ve sent over the past 45 days. Similar to the Postmark UI, you’ve been able to search by subject, from email, recipient, and tag. But unlike the UI, you’ve never been able to search by date or by status. Today we’re releasing a set of updates that brings the UI and API on par with each other so that you may search for inbound or outbound messages through the the API by date, status, plus all the usual filtering options. For example, you may now find any Inbound messages that failed to process to their webhook.

GET /messages/inbound?offset=0&count=20&status=failed&fromdate=2015-08-18

This search will return a list of any messages that failed to process to your webhook endpoint from August 19th 2015. Other inbound statuses you can search are failed, queued, blocked, scheduled, or processed (default).

Opening up the Messages API to be able to search by status has given way to another actionable endpoint for users, inbound message retrying. When an inbound messages fails to post to a user’s webhook, it goes into a retrying or “scheduled” state in the Postmark activity listing. If all the webhook post retries fail to return a 20x http status code, the message was considered “failed” and was not able to be retried by users.

Today we’re introducing a new endpoint to allow users to do just that. Since you can now search inbound messages by status, it’s possible to search by status=failed to return a listing of messages that failed to process. If you’ve corrected whatever issue was causing the webhook to fail, you can retry the messages on you own using the new API call and the MessageID of the failed message.

PUT /messages/inbound/[MessageID]/retry

This was an oft-requested feature and we’re excited to now offer this functionality.

The Postmark Inbound system has always been robust and easy to setup. We’ve supported inbound MX forwarding for years now but today we’re updating that functionality to include wildcard subdomains. To use a wildcard domain, instead of supplying a domain such as “inbound.mydomain.com” you can simply use “*.mydomain.com” and setup a matching record in your domain DNS settings. With this setup, users can send messages to someone@client1.mydomain.com or someoneelse@client2.mydomain.com and the messages will all arrive and process on the Postmark server with the wildcard domain.

A good example of why this is useful is if you are servicing multiple users or development environments using Postmark Inbound processing. It’s not practical to setup a Postmark server for each customer with an inbound domain like “customer1.mydomain.com”, “customer2.mydomain.com”. With inbound wildcard domains, you can simply setup a “*.mydomain.com” record on your Postmark server and all the inbound messages for subdomains of mydomain.com will process on that server.