Skip to main content

Requirements for your page

Header enrichment is the only flow where the subscriber's browser reaches us directly. That makes your page part of the integration in a way it is not elsewhere, and it is why most header enrichment problems are in the page rather than in the API call.

Five things your page must do​

1. Be reached over the operator's mobile data. Enrichment is the operator identifying the number from the connection. On Wi-Fi there is no number to identify, so keep a PIN flow as the fallback and detect the failure rather than assuming.

2. Fetch the anti-fraud script from your backend, with flow=he.

GET /api/sp/v1/dcb/antifraud/script?shortCode=…&serviceId=…&ti=…&ts=…&te=…&flow=he

3. Set te to the element the subscriber actually taps: the confirmation control, not the page. See Anti-fraud.

4. Send the subscriber to the enrichment endpoint, carrying the same ti and ts.

GET /he/v1/subscribe?serviceId=…&ti=…&ts=…

ts is a Unix timestamp in seconds, and it is checked: a redirect older than the freshness window is refused, so a link that gets forwarded or posted in a group chat cannot enrich whoever opens it tomorrow. Generate it when you build the URL, not when you build the page.

You do not send the MSISDN. The operator's network supplies it. A number in your query string is not what identifies the subscriber, and would not be trusted if it were.

5. Register your page's origin, and do not suppress the referrer.

Two ways to break this silently

Your registered landing page is matched on ORIGIN only (https://your-domain.example), because browsers strip the path from a referrer on a cross-origin navigation. A registered URL that includes a path can never match real traffic.

And a Referrer-Policy of no-referrer or same-origin sends nothing, so every tap is refused. Both failures produce the same refusal, and the cause is in your page's configuration rather than in anything you can see from the API.

Why the anti-fraud check is stricter here​

In a PIN flow the subscriber proves possession by typing a code they received. In header enrichment there is no second factor: one tap is the whole consent. The anti-fraud verdict is therefore not one signal among several; it is the only one. Expect it to be applied without leniency, and do not design a flow that assumes a marginal case will pass.