Global Email:Result Codes: Difference between revisions
No edit summary |
No edit summary |
||
Line 6: | Line 6: | ||
{{CustomTOC}} | {{CustomTOC}} | ||
==Result | ==Result Codes (Advanced)== | ||
Result codes yield more granular information about a given email. They are returned as a comma-delimited string of 4-character alpha-numeric codes, e.g. “ES01,ES07,ES21” or “EE04,ES22”. | |||
The following section details the result codes used by Global Email, and the final section of this page gives our general recommendations for handling our result codes. | |||
==Result Codes== | |||
The Global Email Result Codes are listed here: [[Result Code Details#Global Email|Global Email Result Codes]]. | |||
Refer to [[Global Email:Response|Response Fields]] for our full documentation on each field in our responses, and our [[Global Email:REST JSON|examples]] for each format for more information. | |||
===ES## and EE## Codes=== | |||
The ES## and EE## codes (Email Status and Email Error) are returned alongside each email record in a request. | |||
===SE## and GE## Codes=== | |||
The SE## and GE## codes (Transmission Service Error and General Transmission Error) are used to signify more general errors, and are returned under the key “TransmissionResults” in the outermost level of our responses. | |||
For | ==Using Result Codes== | ||
In general, we recommend using the equivalent of a <code>string.contains()</code> method to check our result codes. | |||
Looking for exact matches between two result code strings could result in false negatives, since a valid email could come back with either “ES01,ES21” or “ES01,ES22,” where the only difference between those two is the last character, signifying that one was retrieved from our cache and the other in real-time. | |||
While our result codes allow for very granular analysis, a general use case could entail something like the following: | |||
<pre> | |||
# Pythonic pseudocode | |||
resultCodeStr = "ES01,ES10,ES22" | |||
# This indicates that the email is valid based on a real-time check, | |||
# and that we successfully fixed the syntax of the original input. | |||
if resultCodeStr.contains("ES01"): | |||
# valid email | |||
handleGoodEmail() | |||
elif resultCodeStr.contains("ES10"): | |||
# you may want to update your records with our fixed email | |||
handleFixedEmail() | |||
elif resultCodeStr.contains("EE"): | |||
# any one or more EE## codes indicates a bad email | |||
handleBadEmail() | |||
# Few users will need to account for every single individual result | |||
# code, but more granular analysis beyond the above is easily | |||
# implemented.</pre> | |||
While changes in result codes are rare outside of major releases, using string.contains() or equivalent is the most future-proof way to handle our result codes. | |||
For example, the result code ES02 was deprecated after Global Email version 3. However, even with version 3, any email that came back with ES02 always had at least one EE## code as well, so any implementation using EE## codes to filter out bad emails would have been forward compatible with no changes needed. | |||
We believe result codes are especially useful for marketing campaigns involving high volumes of emails. Such campaigns are sensitive to problems such as spam traps and accept-all emails, as both of those factors could lead to significantly decreased ROI. While these factors are reflected in the Deliverability Confidence Score, we recommend explicitly filtering out and handling such emails for applications such as marketing campaigns. | |||
Please refer to [[Global Email:FAQ#Accept-all Emails|Accept-All Emails]] for more information on accept-all emails, and why they are a problem in the world of email verification and email marketing. | |||
[[Category:Global Email V4]] | [[Category:Global Email V4]] | ||
[[Category:Reference]] | [[Category:Reference]] |
Latest revision as of 23:23, 10 August 2020
Global Email Navigation | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
| ||||||||
| ||||||||
| ||||||||
Sample Code |
Result Codes (Advanced)
Result codes yield more granular information about a given email. They are returned as a comma-delimited string of 4-character alpha-numeric codes, e.g. “ES01,ES07,ES21” or “EE04,ES22”.
The following section details the result codes used by Global Email, and the final section of this page gives our general recommendations for handling our result codes.
Result Codes
The Global Email Result Codes are listed here: Global Email Result Codes.
Refer to Response Fields for our full documentation on each field in our responses, and our examples for each format for more information.
ES## and EE## Codes
The ES## and EE## codes (Email Status and Email Error) are returned alongside each email record in a request.
SE## and GE## Codes
The SE## and GE## codes (Transmission Service Error and General Transmission Error) are used to signify more general errors, and are returned under the key “TransmissionResults” in the outermost level of our responses.
Using Result Codes
In general, we recommend using the equivalent of a string.contains()
method to check our result codes.
Looking for exact matches between two result code strings could result in false negatives, since a valid email could come back with either “ES01,ES21” or “ES01,ES22,” where the only difference between those two is the last character, signifying that one was retrieved from our cache and the other in real-time.
While our result codes allow for very granular analysis, a general use case could entail something like the following:
# Pythonic pseudocode resultCodeStr = "ES01,ES10,ES22" # This indicates that the email is valid based on a real-time check, # and that we successfully fixed the syntax of the original input. if resultCodeStr.contains("ES01"): # valid email handleGoodEmail() elif resultCodeStr.contains("ES10"): # you may want to update your records with our fixed email handleFixedEmail() elif resultCodeStr.contains("EE"): # any one or more EE## codes indicates a bad email handleBadEmail() # Few users will need to account for every single individual result # code, but more granular analysis beyond the above is easily # implemented.
While changes in result codes are rare outside of major releases, using string.contains() or equivalent is the most future-proof way to handle our result codes.
For example, the result code ES02 was deprecated after Global Email version 3. However, even with version 3, any email that came back with ES02 always had at least one EE## code as well, so any implementation using EE## codes to filter out bad emails would have been forward compatible with no changes needed.
We believe result codes are especially useful for marketing campaigns involving high volumes of emails. Such campaigns are sensitive to problems such as spam traps and accept-all emails, as both of those factors could lead to significantly decreased ROI. While these factors are reflected in the Deliverability Confidence Score, we recommend explicitly filtering out and handling such emails for applications such as marketing campaigns.
Please refer to Accept-All Emails for more information on accept-all emails, and why they are a problem in the world of email verification and email marketing.