How to Connect Keitaro Traffic Source Postback to Adgora

Prerequisites before you start

Before you try how to connect Keitaro traffic source postback to Adgora, make sure both accounts are active and you can edit the traffic source in Keitaro. That sounds plain, but this is where many setups stall: a user has admin access in Adgora, yet only view access in Keitaro, so the postback field stays locked. You need the exact Adgora account you want to send events into, and you need the traffic source entry in Keitaro that actually receives clicks.

Check three things first. One, the Keitaro traffic source must already exist. Two, you must know which offer or campaign will generate the conversion event. Three, you need the identifiers that Adgora expects in its account settings. If any of those are missing, stop there and fix access before you paste a single URL.

In practice, the cleanest setup is to open both tools in separate tabs and compare the source name, the postback field, and the click identifier field side by side. Small typo, big problem. A traffic source called “Meta US” in Keitaro and “meta_us” in Adgora can still work, but only if the actual parameters match, not the label you use for your own convenience.

If you want a broader refresher on reporting terms before wiring the request, the ad tech glossary can help with the basic words that keep showing up in tracking screens. It is also worth checking the rest of the crypto advertising, monetization & Ad-Tech guides if you are building a fuller tracking stack, because postback setup rarely lives alone.

Find the Adgora postback endpoint and required parameters

The first technical step is to copy the Adgora postback endpoint from the Adgora account area where conversions are configured. Do not guess the URL. Do not reuse a postback from another account. A single character in the endpoint path can turn a valid conversion into a silent failure, and silent failures are the worst ones because they look like “no traffic” instead of “bad setup.”

Adgora will usually expect a base endpoint plus several parameters that identify the event. In a traffic-source postback setup, those parameters often include a click ID, a source identifier, and a conversion reference. Keitaro must send whatever Adgora uses to connect the event back to the right source row. If the source row is wrong, the conversion lands in the wrong place or not at all.

Copy the endpoint exactly as shown in Adgora, then note which macros Adgora lists for the request. Some teams keep a text note with the endpoint, the HTTP method, the required parameter names, and any optional values like payout or status. That note saves time later, especially when a second traffic source needs the same pattern.

If your Adgora account is used for crypto campaigns, the setup logic is the same, whether you run a crypto ad network for publishers workflow or something else. The postback still needs the right identifiers. Nothing magical happens because the campaign is crypto-related.

Build the postback URL in Keitaro

Open the traffic source settings in Keitaro and find the postback or conversion callback field for that source. Paste the Adgora endpoint there, not in the campaign postback box. That distinction matters. Source-level postback sends data from the traffic source configuration itself, which is what Adgora needs for source-based reporting; campaign-level tracking is a different layer and can create confusion if you mix them.

Now map the Keitaro tokens to the Adgora parameters. For example, if Adgora expects a click ID, Keitaro must pass the token that contains that click value. If Adgora expects a source name or source ID, Keitaro should send the token tied to the traffic source record, not the campaign name. Keep the mapping literal. Keep it boring.

One careful habit saves hours: write the finished URL in a plain text editor before you save it in Keitaro. Then compare each parameter one by one. A missing ampersand, a copied space, or a token wrapped in the wrong braces can break the request. This is especially annoying when the URL looks fine at a glance.

Some teams test this first with a low-stakes source, such as a small test campaign, before moving into larger buys. That is sensible. If you are also working with niche verticals, such as mobile app install campaigns or forex and trading offers, the same postback logic still applies, even if the offer page looks completely different.

Match click IDs and source identifiers correctly

This is the part where integrations usually break. Keitaro can receive many IDs, but Adgora only recognizes the event if the exact click or source identifier comes back in the format it expects. If the ID is missing, truncated, or sent under the wrong parameter name, Adgora cannot tie the conversion to the original click.

Use one naming pattern from the start. If your source is “fb_us_01” in Keitaro, keep the same logic in Adgora notes, your tracking sheet, and any internal documentation. A mismatched name does not always break the request, but it does break human troubleshooting. Three different labels for one source can waste an afternoon.

When the Adgora parameter list includes a click ID field, map it to the Keitaro token that stores the click identifier from the source click record. When it includes a traffic-source identifier, pass the source token, not the campaign token. Source identifier and click identifier are not the same thing, and mixing them up can make a conversion appear valid while pointing to the wrong source.

For teams comparing CPA-based flows, the same discipline matters across pricing models too. If you are still sorting out report logic, the article on CPC vs CPM vs CPA is a useful companion, because the postback only tells you what happened; it does not explain why you chose that model in the first place.

Send a test conversion and confirm the request

Run one test conversion after the URL is saved. One. Not five. Trigger the event in a controlled way, then check both systems. In Keitaro, open the source or campaign log and look for the outgoing request, the HTTP code, and the final URL that was sent. In Adgora, look for the matching event record and the timestamp. Those two timestamps should be close, even if they are not identical to the second.

If Keitaro shows a 200 response but Adgora shows nothing, the request reached something, just not the intended event handler. If Keitaro shows a 4xx code, the endpoint, method, or parameter names are likely wrong. If the request never appears in the log, the token placement in Keitaro is probably wrong, or the source postback never saved.

Use a single test click with a unique note in your logbook. For example, “manual test on Tuesday, 14:20.” That gives you one clean line to search later. A messy test with multiple clicks and no notes looks busy, but it is hard to debug.

The phrase how to connect Keitaro traffic source postback to Adgora only becomes clear when you can match one source click, one outgoing request, and one event inside Adgora. If all three line up, the setup is real. If one is missing, do not move on yet.

Fix the most common source-postback errors

Wrong macro placement is the most common mistake. A token meant for campaign data gets pasted into a source field, or a click ID token is placed where a source ID should go. The request still fires, which is why the mistake is easy to miss. The URL exists, the conversion does not.

URL encoding causes the next layer of trouble. If a parameter contains special characters and the value is not encoded the way Adgora expects, the request may arrive with broken parts. That shows up most often in source names, custom notes, or redirect values. A plus sign can become a space. A slash can split the field. Tiny characters, large headache.

Incorrect method settings also cause failures. If Adgora expects GET and Keitaro sends POST, or the other way around, the endpoint may reject the request or ignore it. Check the method in both tools before you change anything else. Changing three fields at once makes it impossible to know which one fixed the problem.

Duplicated parameters create another quiet mess. Two values in the same field can cause one system to read the first one and another system to read the last one. Keep one parameter per purpose. If you need to test a fallback value, do it in a separate version, not in the live URL.

Sometimes the problem is not the URL at all. The traffic source in Keitaro may be named one way, while the source entry in Adgora expects another account or another network ID. That mismatch can make every request look “valid” but land in the wrong place. Check the account connection before you rework the postback itself.

Go live and monitor the first real events

After the test passes, switch from test traffic to real traffic without changing the rest of the funnel. That means you leave the offer, lander, and routing logic alone while the source postback continues to fire. One change at a time is the rule here. If you alter the funnel and the postback together, you will not know which piece caused a drop in reporting.

Watch the first real events closely. The first 10 conversions are the most informative, because they show whether the source postback keeps firing under normal traffic instead of one manual click. Check the event records in Adgora against the source logs in Keitaro. You are looking for consistency, not just one successful line.

Keep an eye on the source name, the parameter values, and the timing. If one ad set generates conversions but another does not, the issue may be in the source setup rather than the postback itself. A clean live handoff means the same URL, the same tokens, and the same identifier pattern continue to work as traffic volume changes.

If your campaign mix includes other verticals, the reporting habit stays the same. Whether you are sending conversions for dating offers, building crypto advertising, or comparing a new source against old traffic, keep the first live events under review until the logs and records agree. Then keep watching the source postback, because the first quiet failure often shows up after the first clean day, not during it.