.svg){kind=icon}
Overview
Conversion errors prevent your conversions from being properly recorded or attributed. Each error code indicates a specific problem - from missing transaction IDs to security blocks to configuration issues.
This guide provides three interactive tools to help you diagnose and fix conversion errors faster:
- Error Code Lookup: Search any error code to see causes and step-by-step fixes
- Troubleshooting Flowchart: Answer a few questions to find your exact solution
- Diagnostic Generator: Create formatted support tickets with all required details
Interactive Error Lookup
Search by error code number or message to instantly see causes and fixes. Click any card to flip and see detailed troubleshooting steps.
Troubleshooting Flowchart
Not sure which error code you have? Follow the interactive decision tree to find your exact problem and solution path.
Diagnostic Info Generator
Opening a support ticket? Use this tool to generate formatted diagnostic information with all the details support needs to help you faster.
Complete Error Code Reference Table
For quick reference, here's the complete list of all 27 conversion error codes
Hidden Causes & "Gotchas"
Some errors have causes that aren't obvious from the error message alone. Here are the most important hidden causes to know:<
Hidden Cause: Error #13 (Invalid Click) can mean the click is >90 days old. While analytics are kept forever, raw click data is purged after 3 months to manage database size.
What This Means: If an advertiser fires a postback for a click older than 90 days, Everflow no longer has the raw record to match it against.
Fix: This is expected behavior, not a bug. Conversions must fire within 90 days of click for attribution.
Hidden Cause: If "Enforce Advertiser Whitelist" is enabled, any conversion from an unlisted IP/domain is blocked silently without notifying the advertiser.
What This Means: The advertiser thinks they fired the postback successfully (they see 200 OK response), but Everflow rejected it before it reached the system.
Fix: Check Advertisers → Settings → Whitelist. Add advertiser's server IP or domain. Check Advertiser Postback Report to see actual source IP.
Hidden Cause: Error #8 (Duplicate Conversion) can mean "same email used twice" if Email Attribution is enabled.
What This Means: The system is configured to only allow one "Approved" conversion per email address for a specific event.
Fix: If legitimate (e.g., same customer making multiple purchases), enable "Allow Duplicate Conversions" in Offers → Revenue & Payout Tab.
Hidden Cause: When a postback racks up at least 10 consecutive failed attempts and the first-to-latest failure span exceeds 72 hours, Everflow automatically disables it entirely. Everflow fires up to 5 attempts per delivery before logging a single failure in your Postback Report, so 10 failed attempts can be reached with as few as 2 consecutive logged failures. Two failures more than 72 hours apart are enough to trigger deactivation. A fast burst inside a single 72-hour window is not enough on its own. The failures need to keep happening past the 72-hour mark. Only postback delivery methods are auto-deactivated.
What This Means: If your partner postback URL is misconfigured or their server is down, after 10 consecutive failed attempts (as few as 2 logged failures) that stretch past a 72-hour window, Everflow stops trying completely.
Fix: Fix the underlying issue (wrong URL, partner's server down, etc.), then manually re-enable the postback in Partners → Postbacks.
Hidden Cause: In direct linking (Meta, Google Ads), users expect to SEE the Transaction ID in the URL. When it's not there, they think tracking is broken.
What This Means: With direct linking, the TID is generated by ClickScript and stored in a first-party cookie (_ef_transaction_id), NOT passed as a URL parameter.
Fix: Check DevTools → Application → Cookies → Look for _ef_transaction_id. If present, tracking IS working (you just can't see it in the URL).
What The HTML Pixel Returns
A common question when integrating: what does the pixel send back, and is there a success or fail field to check? The short answer is that there is not one, and knowing why saves a lot of debugging.
The HTML Pixel is a browser-fired pixel against the tracking endpoint, not a REST API. There is no JSON envelope and no status field. What you get is an HTTP status code and a transparent image. The same is true for a base conversion and for an approval or post-conversion event; the only difference between them is the event_id parameter.
A successful conversion
The pixel fires a request like this one:
GET https://your-tracking-domain.com/?nid=1&oid=61&transaction_id=b603b363d93c4304a91e54b430ad7943&event_id=153The tracking endpoint does not answer directly. It first redirects to your conversion domain:
HTTP/1.1 302 Found
Location: https://your-conversion-domain.com/conversion/?redirect=1&event_id=153&nid=1&oid=61&conversion_id=89ad901d99ff4a8985c9c54a9d719086The second request is the one that answers:
HTTP/1.1 200 OK
Content-Type: image/gif
Content-Length: 42
X-Conversion-Id: 89ad901d99ff4a8985c9c54a9d719086
X-Transaction-Id: b603b363d93c4304a91e54b430ad7943
(42-byte 1x1 transparent GIF)The IDs you need come back in the X-Conversion-Id and X-Transaction-Id response headers, not in the body. The body is only the transparent image.
img or iframe pixel on a page just ends on the 200 and the image. If you fire the pixel from a server instead, your HTTP client must be set to follow redirects. If it stops at the 302, the conversion never completes.When it does not work
There are two different failures and they look nothing alike.
A request Everflow refuses outright, an offer ID that does not exist for example, returns HTTP 204 No Content with an empty body. No redirect, no image, no headers.
204 sits in the 2xx success range. Any integration written as "treat any 2xx as success" will count a refused conversion as a good one and never surface it. If you are firing server-side, check for 200 specifically, not for 2xx.
The second failure is the confusing one. The request is accepted, you get the same 200 and the same transparent GIF, but the conversion is then rejected by a rule. The click was not found, the transaction ID was a duplicate, a cap was reached, the event does not belong to that offer, or the conversion fell outside the lookback window.
The reason is not in the HTTP response at all. It is stored against the conversion as an error code, which is exactly what this article documents. So a 200 confirms your request reached Everflow. It does not confirm a conversion was recorded.
| You get back | What it means | Where to look next |
|---|---|---|
| 200 + GIF | The request reached Everflow. The conversion may still have been rejected by a rule. | Check the conversion's error code in the table above |
| 302 | Only the first hop. Your client is not following redirects. | Enable redirect following on your HTTP client |
| 204, empty | Refused outright. Nothing was recorded. | Check your nid, oid and event_id are real and belong together |
Where to Find Error Codes
Error codes appear in multiple locations depending on how you're tracking conversions:
Add columns:
Rejected conversions show a red
Shows:
• Raw postback URL received
• HTTP response codes (200, 204, 400, 403, 500)
• Error details if postback was rejected
This is essential for diagnosing "postback fired but no conversion appeared" scenarios.
Click the
Common CSV import errors include "Reached Cap" (conversion in Pending status, not rejected) and formatting errors.
Related Resources
• Understanding S2S Postbacks
• How To Test Partner Postbacks
• Accessing & Editing Postback URLs
• Platform-Specific Postback Configurations
Attribution & Methods:
• Conversion Attribution Priority
• Choosing a Conversion Method
• Clickless Conversion Tracking
Troubleshooting:
• Click Error Code Reference
• Everflow Server IPs (for firewall whitelisting)
• IP/Domain Whitelisting Guide
