Preparing For Asynchronous Suppressions
This article describes how to tell if you are affected by the upcoming transmissions API endpoint change for asynchronous suppressions described here and also how to prepare.
What Is Changing?
The change announcement here has all the details including timing. Here is a short recap.
The Transmissions API endpoint will no longer return
400when you send to a single recipient who appears on a suppression list.
bounceevent will include the following fields:
Recipient address was suppressed due to customer policy
Recipient address was suppressed due to system policy
Am I Affected?
You may be affected if:
The proportion of customers who fall into these categories is likely extremely low and, after this change, the main detectable difference for most API users will be a slightly lower level of API call errors.
How Do I Prepare?
Note: While keeping your SparkPost client library up-to-date is always a good idea, updating will not negate this change since it affects how your code and 3rd party apps interpret the information that SparkPost provides.
In most cases, your existing code will continue to work as before. If you fall into one of the categories outlined above, you should take the following actions:
- If you process
policy_rejectionevents to detect suppressions, begin also processing
bounceevents as specified above.
- If you detect suppressions in your single-recipient transmissions calls by checking for
400status and a suppression error message, you app will continue to function but your suppression detection code will become redundant. If you need to detect suppressions, use the
bounceevent specified above.
Will My 3rd Party Apps Still Work?
In the vast majority of cases, 3rd party apps integrated with SparkPost will continue to function as before. If you are unsure, please check with your 3rd party provider for details and direct them to this page and our announcement of this change.
For instance, the SparkPost WordPress plugin will continue to function with a slight change in behaviour. Before the change, the plugin produces an error when sending a single-recipient transmission to a suppressed address. After the change, those single-recipient, suppressed transmissions will succeed and a
bounce event will be emitted instead.