We have just finished adding support for user data attributes to our Subscriptions API. The list and read methods have been enhanced to display all of the user data attributes that have been collected for the given subscriber, along with their corresponding values. This includes the default user data attributes (first_name, last_name, city, etc) in addition to any custom user data attributes that you have defined for your account. The create and update methods have been enhanced to allow you to specify user data attribute values for your subscribers. Storing data for your subscribers allows you to segment your subscription list, targeting messages only to users whose data matches the criteria you define. This means you no longer have to worry about troubling your male customers with sales offers for woman’s apparel. You can see the changes in our API Documentation.
Non Backwards Compatible Changes
Unfortunately, some of the changes are not backwards compatible with previous versions of the Subscriptions API.
Some attribute names will be different in the new version of the API
Previous versions of the API returned very basic information about the subscriber. Some of that information was re-structured when we added support for custom user data attributes. We would like future APIs that also interact with custom data attributes to use consistent names for the attributes. So, we’re biting the bullet now by making this change. The API name for all data attributes, which is the name to use when referring to a given attribute in the API, can be found in the User Data section of the application.
Result from the list method will now be paged
In previous versions of the API, there was no way to limit the number of subscribers you would get back with a call to the list method. If you had 100,000 subscribers, calling the list method would return an XML response approximately 1,500,000 lines long. That can be quite a bit to swallow, and could choke some applications running on machines with limited resources. Now, the list method will return 250 subscribers at a time, and allow you to iterate through your subscribers by specifying a page attribute in the request. For example, not specifying the page attribute would return subscribers 1-250. Specifying page=2 in the request URL will return subscribers 251-500. Specifying page=3 will return subscribers 501-750, and so on. This should give you more control over the API response.
User data attributes with no value for the subscriber will not be displayed
In previous versions of the API, we returned all of the user data attributes, all of the time. Even if the subscriber had no data for that particular attribute. This wasn’t too big of an issue when we were working with a fixed set of attributes. However, you now have the ability to create as many user data attributes as you wish, which could dramatically increase the size of the API response. So, we’ve changed the list and read methods to only list the user data attributes that have corresponding values for the given subscriber. If you don’t see a particular data attribute for a given subscriber, it means that subscriber has no value for that particular attribute.
Testing The New API Methods, and Migrating Your Code
The new API methods are in production, and ready for testing. The create, update, and delete methods are completely backward compatible, so you should be able to continue using them as you were. To access the new versions of the list and read methods, simply add ?new=true to the end of your request. For example, /api/subscription_campaigns/{campaign_id}/subscriptions.xml will invoke the old list method, and /api/subscription_campaigns/{campaign_id}/subscriptions.xml?new=true will invoke the new method. This will allow you to test the new and old API methods side by side, and switch to the new version of the API methods at your convenience.
In a few weeks, after everybody has migrated to the new version of the API, we will make the new versions of the API methods accessible without the ?new=true URL parameter, and you can remove the ?new=true URL parameter at your convenience.
If you have any questions, comments, or concerns, please don’t hesitate to contact us at support@interactivemediums.com.













By “killer feature”, I mean a feature so awesome that when you see it in action, you say to yourself, “I need one of those!”.











