When using /api-registration, you are responsible for redirecting the registrant into AStream after a successful registration.
There are two supported approaches, depending on your level of access to the API response.
Recommended Approach: Use joinURL
If your system has access to the full /api-registration JSON response, you should redirect users to the joinURL returned in that response.
This is the preferred and most direct integration method.
Why this is recommended
It requires no additional redirect logic
It avoids dependency on IP-based validation
It works regardless of device/network changes
It is the cleanest developer implementation
Example Flow
Submit POST /api-registration
Receive JSON response
Extract:
joinURLImmediately redirect the browser to joinURL
That’s it.
If you can access joinURL, you do not need /join?wtl=.
Fallback Option: /join?wtl={wtl}
AEvent provides the following endpoint:
https://{tenant}.aevent.online/join?wtl={wtl}
This exists specifically for environments where:
You cannot inspect the API response body
You cannot parse JSON
You only have access to a static “Redirect URL” field
You need a URL pattern you can construct manually
It is a compatibility bridge — not the primary integration method.
When to Use /join?wtl=
Use this endpoint only if:
You cannot access joinURL from the API response
You can capture and store the wtl value
The redirect happens immediately after registration
The registrant’s IP address was captured at registration
Critical Requirement: IP Address Must Be Captured
The /join?wtl= endpoint relies on session validation that includes IP awareness.
You must satisfy one of the following:
Option A (Preferred)
/api-registration is called directly from the registrant’s browser.
In this case, AEvent can naturally observe the client IP.
Option B
You explicitly pass:
{
"ipAddress": "USER_PUBLIC_IP"
}
If you are registering server-to-server and do not send ipAddress, the redirect may fail.
If operating behind a proxy or CDN, ensure you pass the real client IP (typically the first value in X-Forwarded-For).
It Must Be Used Immediately After Registration
/join?wtl= is intended strictly as an immediate post-registration redirect.
It should NOT be:
Sent in emails
Stored for later use
Used across devices
Used after a network change
If the registrant’s IP changes between registration and redirect, validation may fail.
Think of it as a bridge from registration → live session, not a permanent join link.
Implementation Steps (Fallback Method)
If you must use /join?wtl=:
Step 1: Call /api-registration
Submit:
POST /api-registration
Include:
Contact details
Event ID
ipAddress (if server-side)
Step 2: Capture the wtl
From the response, extract:
wtl
You do not need to parse:
joinURL
platformURL
Store wtl temporarily for immediate redirect use.
Step 3: Redirect
Redirect the browser to:
https://{tenant}.aevent.online/join?wtl={wtl}
The endpoint will:
Validate the session
Issue a 302 redirect
Forward the registrant to the secure AStream session URL
Verifying Behavior
You can confirm correct behavior using:
curl -s --head https://{tenant}.aevent.online/join?wtl=YOUR_WTL | grep location
You should see a Location: header pointing to an aevent.stream URL.
Common Failure Scenarios
Redirect fails intermittently
Most common causes:
IP mismatch
VPN toggling
Device switching
Server-side registration without ipAddress
Works with joinURL but not /join?wtl=
This indicates:
IP was not captured
Redirect is not immediate
The environment is not preserving session integrity
Decision Tree
Use this simple rule:
If you can access joinURL → use it.
If you cannot access the API response and only have a redirect field → use /join?wtl=.
Summary
/join?wtl= exists to support limited environments where developers cannot directly use the joinURL returned by /api-registration.
It is:
A redirect bridge
IP-aware
Intended for immediate use only
For full API integrations, always prefer joinURL.