Statuses flow in from partners; conversions flow out to your source and ad platforms.
Two flows meet here. Statuses come in from the advertiser; conversions go out to whoever needs to know — your traffic source and your own ad platforms. They're separate directions, wired independently.
d0pe pulls status on a schedule: it calls the partner's status API over a date range, matches each item to your lead by external id, maps the partner's status onto your internal ones (auto-creating unknown statuses), and on an FTD promotes the lead to a depositor and records the deposit. A failed or unparseable pull touches nothing — the lead keeps its last good status. A durable partner id keeps sync working even if the originating campaign is later deleted.
When a lead reaches an event — registration, rejected, call, deposit (FTD, the main goal), or redeposit — d0pe fires the postback rules that match. A single event, say a deposit, can fan out to several destinations at once.
A rule can narrow when it fires. This matters most on the call event, which occurs on every status change the partner reports: without conditions your tracker is told about wrong numbers and no-answers exactly as loudly as about approvals.
Narrow by call-status category — the Good / Bad / Trash / No answer buckets you defined under Settings, referenced by name so renaming a raw status re-classifies your rules automatically — or by exact status, country, partner or flow. Conditions combine with AND, and leaving them empty means the rule fires on everything.
Because several rules may share an event and an adapter, separated only by their conditions, you can route good calls to one tracker and rejects to another.
Under Postbacks → Telegram bot, connect a bot (make one with @BotFather, paste its token — it's verified on save and stored encrypted, never shown again) and give each group or channel a name. Add the bot to the chat, hit Test to confirm it can post, and then any postback rule can deliver to that chat by name. The message is a template with the same macros as a URL — “New {status} lead from {country}, payout {payout}” — with optional HTML or MarkdownV2 formatting. Send test fires it with sample data first, which is where a formatting mistake shows up rather than on a live lead.
Every URL and Telegram rule has a Send test button: it fires once with sample data through the exact path a real event uses and reports the result — delivered with its status code, or the reason it didn't. Outbound URLs are checked first: a postback aimed at a private or internal address is refused, so the CRM can't be turned into a proxy for reaching things it shouldn't.
The two flows above are push. There is a third, and it is a pull: a traffic provider can ask you for the current state of the leads it sent, over GET /api/ext/leads, authenticated with the same token it ingests with. It only ever sees its own leads, can filter by date range and by status (LEAD, FAILED, DEPOSITOR, UNASSIGNED), and for a lead the brand rejected it gets the partner's full response body back — so it can see the reason without asking you. Use it when a provider wants reconciliation rather than event-by-event postbacks; the exact contract is in the API reference.
Rules are team-wide (the owner/team-lead global rule) or a buyer's personal override. A buyer who defines any rule for a destination takes that destination over completely for that event — their rules replace the team's rather than running alongside them, which would otherwise double-report every conversion. Adapter configs hold secrets (CAPI tokens, API keys) and are encrypted at rest; a per-lead log shows every postback fired. Traffic providers are inbound-only — a provider's postbacks are simply the rules of its owner user, shown per provider.