Postbacks #
A postback is an HTTP request that Monetag sends to your server after an ad event in your Mini App is confirmed. You don’t write tracking code for it: Monetag records the impression or click, checks it and calls your URL with the result. On your side it takes one URL with macros, set for your main zone in the Monetag SSP.
Each postback tells your server:
- what happened:
impressionorclick, and which zone delivered the ad; - whether the event is paid:
reward_event_typeisvaluedornon_valued; - the estimated earnings for the event,
estimated_price; - the
ymidyou passed to the SDK, and the Telegram user ID when Telegram provides it; - where in your UI the ad was shown,
request_var. Its value depends on the format, see the Macro Reference.
If your server does not accept a postback, Monetag retries it for up to about 38 hours.
Postbacks are sent for Rewarded Interstitial, Rewarded Popup and In-App Interstitial. In-App Interstitial sends impression postbacks only, no click.
How It Works #
%%{init: {"sequence": {"width": 110, "actorMargin": 30}}}%%
sequenceDiagram
autonumber
actor U as User
participant A as Mini App
participant M as Monetag
participant S as Your server
A->>U: show_XXX({ ymid })
U->>A: Watches or clicks
A->>M: Impression or click
Note over M: Confirms the event:<br/>valued or non_valued,<br/>estimated price
par Postback
M->>S: GET postback URL
Note over S: Reward once per ymid<br/>if valued
S-->>M: 2xx, or a retry
and Frontend Callback
M-->>A: Promise resolves
end- Your app calls
show_XXX()with aymidthat is unique for this ad show, and the SDK shows the ad. - The user watches or clicks the ad.
- The impression or click reaches Monetag. Monetag confirms the event and decides whether it is paid.
- Monetag sends a GET request to your postback URL, with the macros replaced by the event data. Your server grants the reward if
reward_event_typeisvalued, once perymid. - Your server answers with 2xx. Otherwise Monetag retries the postback.
- In parallel, for Rewarded Interstitial and Rewarded Popup, the SDK Promise in your app resolves with a subset of the event data:
ymidarrives asvariable2, andestimated_priceis absent fornon_valuedevents. See What You Get in the Callback. The Promise and the postback are delivered independently, so don’t rely on their order.
Example request for a Rewarded Interstitial impression:
GET https://your-backend.com/postback?secret=YOUR_SECRET&ymid=user-42_ad_7&event_type=impression&reward_event_type=valued&zone_id=123456&sub_zone_id=123456&request_var=bonus_button&telegram_id=123456789&estimated_price=0.0037000
Why Not Reward on a Request from Your App #
A common alternative is to let the app tell your server that an ad was shown, for example after show_XXX() resolves, and grant the reward on that request. The request comes from the user’s device, and this is where it breaks:
flowchart TB
subgraph app["Request from your app"]
direction TB
a1["Ad is shown"] --> a2["App asks your<br/>server for a reward"]
a2 --> a3["Reward granted,<br/>paid or not?"]
x1["Forged request<br/>devtools, script"] -.->|"no ad watched"| a2
a2 -.->|"app closed"| x2["Request lost"]
end
subgraph pb["Monetag postback"]
direction TB
b1["Ad is shown"] --> b2["Monetag confirms<br/>the event"]
b2 --> b3["Postback with<br/>valued / non_valued,<br/>estimated price"]
b3 --> b4["Reward granted<br/>only if valued"]
b3 -.->|"no 2xx: retries<br/>up to ~38 h"| b3
end
app ~~~ pb
classDef risk fill:#fdecea,stroke:#c62828,color:#000
classDef ok fill:#e8f5e9,stroke:#2e7d32,color:#000
class x1,x2,a3 risk
class b4 ok| Reward on a request from your app | Reward on a Monetag postback |
|---|---|
| Easy to forge. The user controls the device. The same request can be sent from browser devtools or a script, and your server grants rewards for ads nobody watched. | The postback comes from Monetag’s server. Your postback URL is stored in Monetag and never reaches the app, so you can add a secret parameter to it and reject requests without it. |
| Lost on exit. If the user closes the app or loses the connection before the request is sent, the reward is lost. | Monetag sends the postback from its server after the event is confirmed and retries failed deliveries for up to about 38 hours. |
Payment status you can’t trust. On rewarded formats, the SDK Promise gives your app reward_event_type and estimated_price, but your server gets them only as the device reports them. A modified app can report any event as valued. | The postback carries reward_event_type and estimated_price from Monetag’s server. Reward only valued events. |
| Code to maintain. Tracking has to be written and maintained for every format and placement. | One URL for the main zone covers all formats. {sub_zone_id} and {request_var} tell formats and placements apart. |
This holds even if the app sends its request after the SDK Promise resolves: the Promise result is confirmed by Monetag, but the request to your server still comes from the user’s device.
Postback and Frontend Callback #
When you call show_XXX(), the SDK returns a Promise. This mechanism is known as a Frontend Callback.
For Rewarded Interstitial and Rewarded Popup on zones with reward postback (enabled by default), the Promise resolves with the event data after Monetag confirms the event. It rejects with Failed to verify the ad show if no confirmation arrives. For In-App Interstitial and for the preload and start types, it resolves with no value.
show_XXX().then((result) => {
// Frontend Callback triggered
// Reward the user if result?.reward_event_type === 'valued'
});
Backend confirmation is on by default for rewarded formats. It can be turned off per SDK zone on request.
⚠️ Important: A resolved Promise does not mean the event was monetized. Check reward_event_type in the result.
| Use Case | Frontend Callback | Server-Side Postback |
|---|---|---|
| Show success message | ✅ | Optional |
| Track exact monetization | ❌ | ✅ |
| Reward user with coins | ⚠️ Risky | ✅ |
| Trigger analytics event | ✅ | ✅ |
| Fraud protection | ❌ | ✅ |
| Offline reliability | ❌ | ✅ |
Use the Frontend Callback for the UI and the postback for rewards and accounting. You can use both in parallel.
Set It Up #
- How to Configure Postbacks: the URL in the SSP and your endpoint.
- Macro Reference: every value a postback can carry.
- Types of Postback Events: what
impressionandclickmean for each format. - Testing and Verifying Postbacks: how to check your setup.