First of all, congrats on V3 of the API - many improvements!
We are receiving a lot of requests about two features, that would improve the speed/value of our Dynamics CRM integration with Campaign Monitor alot (CMCRM):
1) Retrieving Changed subscribers on lists
Business Case: Right now we can only retrieve new subscribers since the last sync, and even if we were to choose to retrieve all subscribers, we only have the "Created On" date, so we cannot determine if the subscriber has changed, unless we iterate and lookup all in Microsoft CRM, which is not an option.
Suggested solution: If you have the "ModifiedOn" field available in the DB, we would love if you could either add the field to the "GetActive" call, or make a specific call for getting modified subscribers.
2) Retrieving bounces on Campaigns
Business Case: When we retrieve Opens, Click and unsubscribe events, we have the "date" parameter, so we can retrieve the latest, since the last sync date. But the "Get Bounces" call, does not take this parameter. This means we have to retrieve every bounce since the Campaign Launch, then iterate all of them to determine if there are any new Bounces. This slows down the synchronization severly since we have customers using CMCRM who are synchronizing campaigns with 20.000+ bounces.
Suggested solution: Align the "Get Bounces" call, to match the signature of the other campaign even calls, adding the "date" parameter as well.
I Hope you can give me some feedback, so I can tell our customers, if these features are a part of the roadmap for future releases of the API - and possibly an aproximately release date would be great ;)
Michael Randrup / Applications A/S
Your first request can be completely met by using a webhook on the "Subscriber Update" event. Documentation for available list-based webhooks is at: http://www.campaignmonitor.com/api/webhooks/#currently_available_webhooks
Your second request could also be achieved on a list-by-list-basis by using a webhook on the "Subscriber Deactivate" event. You would register the webhook for the lists to which your campaign was sent, which is easily achieved by using the API, and you would then check whether the subscriber state was "Bounced" when your URL handled the deactivate event.
Webhooks are very much suited to the type of processes which involve synchronisation between two data sources, which is quite a common requirement of many Campaign Monitor API developers.
Thank you for your reply. And yes, we know about the Web Hooks and what they can do.
The problem is, that CMCRM is a commercial standard solution for Dynamics CRM / Campaign Monitor. See your download page: http://www.campaignmonitor.com/downloads/microsoft-dynamics-crm/
Web Hooks requires that the "hooking" page can be integrated with the CRM system. Almost every Dynamics CRM deployment does not have public access to their CRM System, so we cannot rely on the web hooks. We have to rely on the capabilities of the API's unfortunately.
Do you have any information on, if these features are on the API Roadmap, so I can relay this information to the customers who have asked us about this?
Thanks in advance.
I think that it would be in the best interests of *any* third party piece of software which does synchronisation between Campaign Monitor and another system (including CMCRM), to take the advice of Campaign Monitor when it comes to making decisions about the best way to do synchronisation.
I'm suggesting that we introduced webhooks as a well established and well documented standard way of doing this, and so it stands as the recommended way of doing list synchronisation. We do not want to duplicate functionality in our API, which is already supported by webhooks.
In your specific case, what is stopping you from including an HTTP-accessible endpoint in your application which can accept requests from our webhook servers and write to the CRM? You are obviously already making requests to our API servers from your application, so why not support additional integration functionality by including endpoints which support webhook requests?
I agree with Michael about improving the API.
Every functionality should be available in an "active" approach in which we can "ask" for new data, changes and so on and a "reactive" one in which via webhooks you inform us of the changes as they happen.
What can we do if our system fails while processing a request from you or if we have to recover from a backup and lost one day of data or if we are doing an upgrade and we don't correctly process the webhook?
We are pretty much stuck.
Webhook are great for quick communication but they should only serve as an extra bonus and not as a primary way of operation.
I agree that bounces should be able to be specified by using a minimum date argument and have already added a feature request for this. Apologies that the date parameter isn't currently there.
The option to retrieve "modified" subscribers via the API is quite a bit more complex and we're still thinking about it.
Just letting subscribers to this topic know that we've added support for the date argument when retrieving bounces for a campaign.
Announced in our API Announcements forum.