Test & Troubleshoot a Postback URL

You can test a postback URL before you rely on it in production. This helps you confirm that your endpoint accepts the request and isolate delivery issues faster.

Test your Postback URL

Note: When testing, we recommend temporarily modifying your Postback URL to pass a hard-coded test value (e.g., "12345678" instead of {SubId1}) to avoid errors. If your server accepts the submission, you can safely revert your Postback URL back to use the variable.

1. From the top navigation bar, select Discover → My Brands.

2. Proceed based on your view:

   • For [Grid View], select the brand from which you want to test a postback, then select [More] → Tracking Integration.

   • For [List View], hover over the brand from which you want to test a postback, then select [More] → Tracking Integration.

3. In the Postbacks section, find the postback URL you'd like to test, then select [Action] → Test.

4. Fill in the URL you'd like to test, then select Start test.

   

Understand retry behavior

If a postback fails when impact.com posts to your destination URL, impact.com retries delivery automatically. This helps account for temporary network issues or short periods of server unavailability.

impact.com retries a failed postback up to 15 times in total.

impact.com does not retry a postback in these cases:

• The destination URL is malformed or invalid.

• The destination URL or its host does not resolve, such as during a DNS lookup failure.

impact.com skips the first 3 retries for HTTP responses from 400 to 500.

Retry attempt	Delay before retry
Retry 1	+15 seconds
Retry 2	+15 seconds
Retry 3	+15 seconds
Retry 4	+3 minutes
Retry 5	+3 minutes
Retry 6	+15 minutes
Retry 7	+15 minutes
Retry 8	+15 minutes
Retry 9	+2 hours
Retry 10	+2 hours
Retry 11	+2 hours
Retry 12	+6 hours
Retry 13	+6 hours
Retry 14	+6 hours
Retry 15	+6 hours

Troubleshoot errors

Error	Description
Missing mandatory parameter	Your server is likely expecting a value instead of a variable. Modify your Postback URL to pass a test value (e.g., "12345678" instead of {SubId1}) and see if it accepts the hard-coded value.
Case-sensitive variables	Dynamic variables are case-sensitive and must be exact, meaning that {SubId1} is not the same as {subid1}. Double-check that your variables reflect the correct case-sensitivity.
Access Denied	Most Postback servers have a security token or value that must be passed along with the dynamic variables. Work with your website's technical team (or refer to your website provider's documentation) to learn about the token or security value needed to access the server.