Parámetros de postback de offerwall: Lootably, AdGate Media, CPX Research y BitLabs

Respuesta corta

Lootably envía {userID}, {transactionID}, {currencyReward}, {revenue}, {ip} y {status}; AdGate Media usa {s1} para el usuario, {points}, {payout} y {state}; CPX Research envía {user_id}, {trans_id}, {amount_local}, {amount_usd} y {status}; BitLabs usa [%USER:UID%], [%TX%], [%VALUE:CURRENCY%] y [%VALUE:USD%]. Acredita cada transacción una sola vez, verifica el hash y trata las reversiones.

Señal de reversión

Lootably: status 0. AdGate: state "rejected". CPX Research: status 2. BitLabs: tipo RECONCILIATION.

Firmas

Lootably: SHA-256. BitLabs: HMAC SHA-1 de la URL completa. CPX Research: una macro de hash seguro. AdGate: ninguna, lista blanca de IP.

La misma idea, cuatro nombres

El ID de usuario es {userID}, {s1}, {user_id} o [%USER:UID%].

Comprobado con

La documentación de postback de cada offerwall, octubre de 2026.

Por qué importan los nombres

Un postback es una petición del servidor del offerwall al tuyo. Dice que un usuario completó una oferta y cuánto acreditarle. Tu endpoint lee unos pocos valores: quién es el usuario, qué transacción es, cuántos puntos dar y, a veces, la IP desde la que empezó la oferta. Si uno de ellos se lee del parámetro equivocado, el usuario recibe mal el saldo, dos veces o nunca.

Cada offerwall te deja montar la URL de postback a tu gusto: eliges los nombres de tus parámetros y pones como valores las macros del offerwall, por ejemplo ?user={userID}&tx={transactionID}. Las tablas de abajo recogen las macros. Los nombres de tus parámetros pueden ser los que quieras.

Para revisar una URL que ya tienes, pégala en el comprobador de postback gratuito: marca cada macro que el offerwall no va a rellenar (mayúsculas mal puestas, el nombre de otro offerwall, llaves codificadas en la URL) y lo que le falta al postback.

Lootably

El hash es el sha256 de userID, ip, revenue y currencyReward seguidos de tu clave secreta de postback, concatenados en ese orden. Lootably documenta status 0 para los contracargos, pero indica que por ahora solo envía postbacks con status 1: ten lista la gestión de reversiones sin depender todavía de ella.

AdGate Media

El ejemplo del propio AdGate es ?conversion_id={conversion_id}&user_id={s1}&point_value={points}&usd_value={payout}&offer_title={vc_title}. Añade {state}: sin él, AdGate solo envía las conversiones aprobadas; con él, una conversión revertida vuelve a llegar con state rejected y el mismo ID de conversión, así que puedes encontrar el abono original y retirarlo.

AdGate no firma sus postbacks. Publica las IP desde las que llegan y te pide usar una URL de postback que solo llame AdGate, así que permite únicamente esas direcciones en ese endpoint.

CPX Research

Un postback típico de CPX es ?status={status}&trans_id={trans_id}&user_id={user_id}&amount_local={amount_local}&amount_usd={amount_usd}&hash={secure_hash}&ip_click={ip_click}. Ojo: una cancelación es status 2, no 0. Un código escrito para otro offerwall que solo mira si llega 0 acreditará las cancelaciones de CPX como si fueran encuestas nuevas.

BitLabs

Las integraciones antiguas usan las formas cortas [%UID%], [%VAL%] y [%RAW%]; la documentación actual de BitLabs usa los nombres de arriba. Una reversión llega como un callback de tipo RECONCILIATION: añade [%REF%] para saber qué recompensa revierte.

BitLabs adjunta un hash a cada callback: un HMAC SHA-1 de la URL completa, en hexadecimal, con tu clave secreta de la app. Como cubre toda la URL, verifícalo antes de leer o modificar nada y usa la URL exactamente como llegó.

Lo que debe hacer todo endpoint de postback

1. Verifica la firma con el método de ese offerwall y rechaza la petición si no coincide.
2. Acredita cada ID de transacción una sola vez. Los offerwalls reintentan cuando tu servidor tarda; un índice único sobre el ID de transacción hace inofensivo el reintento.
3. Trata las reversiones. Ten claro qué valor significa reversión en cada offerwall (status 0 en Lootably, state rejected en AdGate, status 2 en CPX Research, tipo RECONCILIATION en BitLabs) y retira la recompensa, o retenla si aún no se ha retirado.
4. Responde rápido con la respuesta que espera el offerwall, y deja el trabajo lento para después de contestar.
5. Comprueba a la persona, no solo la petición. Un postback bien firmado puede pagar igualmente a una granja: diez cuentas en un mismo móvil, una VPN para parecer de EE. UU., una oferta terminada más rápido de lo que nadie podría jugarla.

Ese último punto es el que ninguna firma cubre. Mira cómo detectar multicuentas en un sitio de recompensas y cómo frenar el fraude con VPN en offerwalls para ver cómo es el fraude que llega con la firma correcta.

Prueba tu endpoint antes de salir en vivo

Cuatro peticiones te dicen si un endpoint está listo. Envíalas tú mismo con curl o desde el navegador, con un usuario de prueba y valores inventados:

1. Una conversión normal. El usuario de prueba recibe el saldo una sola vez, en tu moneda.
2. La misma petición otra vez. No cambia nada: el ID de transacción ya existe, y tu endpoint sigue respondiendo con éxito para que el offerwall deje de reintentar.
3. Una reversión con el valor de estado de ese offerwall. La recompensa se retira o se retiene, y el historial de la cuenta muestra por qué.
4. Un hash incorrecto. La petición se rechaza y no se acredita nada.

Si alguna de las cuatro se comporta de otra forma, corrígela antes de activar el offerwall: cada una es una vía por la que se escapa dinero real.

Revisar cada postback sin programar

El relé de postback de CashoutGuard se coloca entre el offerwall y tu endpoint. Pegas tu URL de postback actual, te da una nueva para poner en el offerwall, y cada conversión se puntúa por VPN, emuladores, móviles en la nube y cuentas vinculadas antes de llegarte. Lee las macros de arriba aunque tus parámetros tengan nombres cortos como ?a={userID}&b={transactionID}, y aprende de las reversiones que llegan con un valor de estado, así que cada contracargo mejora la siguiente decisión.