API de referidos (ref_id)
Añade un ref_id a cualquier solicitud de compra y gana una parte de los ingresos cuando esa activación se apruebe.
Cómo funciona
La mecánica detrás de cada recompensa por ref_id.
Ganas el 5% de los ingresos de cada activación aprobada que lleve tu ref_id. Una excepción: si el beneficio de una venta es muy bajo, la recompensa se limita a una parte de ese beneficio. Este límite nunca se ha aplicado.
La recompensa solo se crea cuando la activación se aprueba, es decir, cuando el código de verificación realmente llega. Una activación cancelada o reembolsada no genera ninguna ganancia.
Las recompensas se abonan en el saldo de tu monedero de inmediato, sin periodo de espera.
Las ganancias de API son crédito en el monedero: no hay mínimo ni solicitud de retiro, pero no se pueden retirar como efectivo. Gástalas en cualquier producto de la plataforma.
Envío de ref_id
Ambas vías de la API aceptan el mismo código de referido; solo cambia la forma de transporte.
API moderna (v1, cuerpo JSON)
curl -X POST "https://smsbulk.net/api/v1/activations" \
-H "x-api-key: YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{
"serviceCode": "wa",
"countryIso": "US",
"ref_id": "K7M2QXWP"
}'{
"id": "act_9f1c...",
"status": "PENDING",
"phoneNumber": "+1...",
"referral": {
"accepted": true,
"reason": null
}
}Vía compatible con SMS-Activate (parámetro de consulta)
curl "https://smsbulk.net/stubs/handler_api.php\
?api_key=YOUR_KEY&action=getNumber&service=wa&country=187&ref_id=K7M2QXWP"ACCESS_NUMBER:12345678:79991234567Las dos reglas que los socios suelen malinterpretar
Estas protecciones evitan autopagos y pagos duplicados. Si una recompensa no apareció, la causa casi siempre es una de estas dos.
El autopago está bloqueado
Si el ref_id pertenece a la misma cuenta que realiza la compra, no se crea ninguna recompensa. Poner tu propio ref_id en tu propio tráfico nunca genera comisión.
Las cuentas ya vinculadas se ignoran
Si el comprador ya se registró con el enlace de referido de ese mismo socio, enviar el ref_id de ese socio en una compra se ignora: la relación ya existe, así que no se crea una segunda recompensa. El ref_id de un socio distinto sigue funcionando con normalidad.
Un ref_id inválido nunca bloquea la compra
Un ref_id desconocido, mal formado o caducado se ignora de forma silenciosa. La compra siempre se completa con normalidad, con o sin un código de referido válido.
El campo referral en la respuesta de v1
POST /v1/activations solo incluye un objeto referral cuando la propia solicitud envió un ref_id. Las solicitudes que nunca lo envían reciben exactamente la misma forma de respuesta que antes.
- accepted: true significa que el ref_id fue aceptado y vinculado a esta activación. La recompensa se registra después, cuando la activación se aprueba.
- accepted: false significa que no se creó ninguna recompensa; consulta el valor de reason a continuación.
valores de reason
| reason | Significado |
|---|---|
| unknown_code | El ref_id no coincide con el código de ningún socio. Los intentos repetidos con códigos inválidos tienen un límite de frecuencia. |
| self_dealing | El ref_id pertenece a la misma cuenta que realizó la compra. |
| already_referred | El comprador ya está vinculado a este mismo socio desde el registro, por lo que el código se ignora en lugar de tratarse como un error. |
| referrer_inactive | La cuenta del socio detrás de este ref_id está inactiva o suspendida. |
La vía compatible con SMS-Activate no tiene campo referral
Ese protocolo devuelve una línea de texto plano como ACCESS_NUMBER:id:phoneNumber, no JSON, así que no hay ningún campo para transmitir el resultado accepted/reason. El ref_id funciona exactamente igual en esta vía; simplemente no puedes ver el resultado en la respuesta. Revisa el panel de socios para confirmarlo.
Empieza a ganar con tu tráfico de API
Obtén tu código de referido en el panel de socios y añádelo a tu integración.