Hi Martin,
The "this" refers to uniquely identifying the UE/session. The API server will need to "lookup" the UE/session in some way (like in a database shared with AAA) to get its state (captive or not, how much time/data remaining, etc). In this regard, the API and the Captive Portal itself *both* need this ability to uniquely identify the UE/session.
Sure, one *could* design an API server, to reside on the same L2 segment as the subscribers, so that it can determine the UE mac address from looking up the remote IP address in the local ARP table. But... in practice, I think the tendency would be to host the API in the same centralized place as the captive portal itself (and share the same database).
In terms of generating a "session-id" ... a lot of this is very implementation dependent. For example, many hotspot systems are integrated with DHCP/RA because the IP address of subscribers may come from AAA (or a PGW in 3gpp). The redirection URL is often "minted" with the right session_id for that session by the backend AAA/PCRF.
Here is one example: