If you want to receive real-time notifications whenever actions you drive are reported, modified, or reversed, you can set up Action Lifecycle Event Notifications to receive those notifications.
Event Notifications can update a third-party system in real-time via HTTP server calls. If you have an event notification set up and a trigger event occurs (like your partnered brand modifying an action you drove), impact.com will send a postback to your provided URL with a notification.
Event notifications, postbacks, and webhooks are all different terms for the same process in the platform. For consistency's sake, the rest of this article will use the term "postback."
Action lifecycle postbacks work by updating you whenever a "non-standard" event happens in the action lifecycle. Non-standard events are events that do not have established dates or time periods in your contract. For example, an action's locking date is a standard, or predictable event as the action locking period is outlined in your contract. An action getting modified, however, is a non-standard event since no time range or set dates exist in your contract, making it non-standard (or unpredictable).
Here are some examples of non-standard action lifecycle events. These will create a postback.
An action you drove is tracked by or reported to impact.com
An action you drove is modified by your partnered brand
An action you drove is reversed by your partnered brand
Here are some examples of standard lifecycle events. These will not create a postback.
While our API is perfectly suitable to provide you with the same information, there are some characteristic and restriction differences between our API and our postback system that would likely make postbacks a preferable solution for you. These include the following:
Postbacks happen in real-time. Postbacks are generated by impact.com and received by you within 15 minutes of a non-standard event happening.
Postbacks have access to more conversion data. Even if you don't see the data point you need in our UI (or our developer reference sheet) when setting up your postbacks, we likely have the data point available if you reach out to your Publisher Account Manager (or contact support).
Postbacks do not have rate limits. When you use impact.com's API, you are subject to rate limits placed on the system. Specifically, when using the impact.com API, you are limited to 1000 API requests for most endpoints, whereas postbacks have no such limit.
To access our developer documentation portal, click here.
Yes! impact.com makes use of postbacks in some of our own tracking solutions. You don't need to meet any special criteria to utilize postbacks, you don't face any rate-limiting, and impact.com will continue to try to reach your server until we receive a 200 or 201 response (meaning you received the information with no issues).
When we perform maintenance of our postback system, you will be notified and postbacks will be paused. However, as soon as we complete the maintenance, we will immediately begin catching your system backup.
However, if you notice a delay with receiving postbacks like an action was modified and you haven't received a postback in over an hour since the modification occurred, contact support.
When using postbacks, you will establish the destination to which you want the calls to be sent. Because of this, because impact.com stores the data on our back-end, and because impact.com performs a server-to-server call when we send the data, there is no way to intercept the data while it is in transit.
If you want, we can create a custom header that conveys another set of credentials to include in the postback calls impact.com sends you. You cannot create this header in the web app, so reach out to your Publisher Account Manager (or contact support) to notify us that you want this header created.