Referral API (ref_id)
Attach a ref_id to any purchase request and earn a share of the revenue when that activation is approved.
How it works
The mechanics behind every ref_id reward.
You earn 5% of the revenue from every approved activation that carries your ref_id. One exception: if a sale's profit is very low, the reward is limited to a share of that profit. This limit has never been applied.
A reward is created only when the activation is approved, meaning the verification code actually arrived. A canceled or refunded activation earns nothing.
Rewards are credited to your wallet balance immediately, with no waiting period.
API earnings are wallet credit: there is no minimum and no payout request, but they cannot be withdrawn as cash. Spend them on any product on the platform.
Sending ref_id
Both API rails accept the same referral code; only the transport differs.
Modern API (v1, JSON body)
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
}
}SMS-Activate compatible rail (query parameter)
curl "https://smsbulk.net/stubs/handler_api.php\
?api_key=YOUR_KEY&action=getNumber&service=wa&country=187&ref_id=K7M2QXWP"ACCESS_NUMBER:12345678:79991234567The two rules partners get wrong
These guards protect the program from self-payouts and double payouts. If a reward did not appear, one of them is almost always why.
Self-dealing is blocked
If the ref_id belongs to the same account making the purchase, no reward is created. Putting your own ref_id on your own traffic never earns commission.
Already-linked accounts are ignored
If the buyer already signed up under that same partner's referral link, sending that partner's ref_id on a purchase is ignored: the relationship already exists, so a second reward is not created. A different partner's ref_id still works normally.
An invalid ref_id never blocks the purchase
An unknown, malformed, or expired ref_id is silently ignored. The purchase always completes normally, with or without a valid referral code.
The referral field in the v1 response
POST /v1/activations only includes a referral object when the request itself sent a ref_id. Requests that never send one get the exact same response shape as before.
- accepted: true means the ref_id was accepted and linked to this activation. The reward itself is written later, when the activation is approved.
- accepted: false means no reward was created; check the reason value below.
reason values
| reason | Meaning |
|---|---|
| unknown_code | The ref_id does not match any partner's code. Repeated probing of invalid codes is rate-limited. |
| self_dealing | The ref_id belongs to the same account that made the purchase. |
| already_referred | The buyer is already linked to this same partner from signup, so the code is ignored, not treated as an error. |
| referrer_inactive | The partner account behind this ref_id is inactive or banned. |
The SMS-Activate compatible rail has no referral field
That protocol returns a plain-text line such as ACCESS_NUMBER:id:phoneNumber, not JSON, so there is no field to carry accepted/reason feedback. ref_id still works exactly the same way on this rail; you simply cannot see the result in the response. Check the affiliate dashboard for confirmation instead.
Start earning from your API traffic
Get your referral code from the affiliate dashboard and attach it to your integration.