Edge Portal overview
Edge Portal is the pre-departure layer of Edge: a tenant-configured portal that takes a booked guest from confirmation to departure day. It treats the booking feed supplied by your reservation system as the source of truth for commercial data and writes guest actions back as events — the portal keeps only the operational state it needs (readiness progress, acknowledgments, delivery tracking).
One product, three surfaces:
| Surface | Who uses it | What it does |
|---|---|---|
| Guest portal | Travelers | Readiness overview, live itinerary with a change feed, pre-travel forms (including on-device passport capture), payments with instant invoice regeneration, and optional extras |
| Travel-agent workspace | Trade partners | Manage their clients' details and forms on the guests' behalf; pre-departure reminders are addressed to the agent, with a configurable handover point after which the portal contacts guests directly |
| Operations console | Your operations team | Readiness dashboard across departures, reminder rules, readiness deadlines, and disruption notices with read receipts |
Key concepts
Date-anchored readiness deadlines. Every pre-departure task — final payment, passport details, forms, transfer confirmation — carries a deadline anchored to the departure date. Reminder rules keep the internal day-offset notation your team plans with (e.g. final balance at departure minus 90 days), but guests always see plain dates: Meridian's guest on the 12 August Best of Italy departure sees "due by 14 May 2026", never "D-90".
The agent and trade model. Bookings arrive on a direct or agent channel. For agent-booked guests the portal opens in a read-only view: guests can see their trip, but details, forms, and payments are managed by the agent of record in the workspace. Reminders target the agent until the configured handover point, after which the guest can be granted full access and contacted directly.
Progressive itinerary release. Itinerary days carry a released flag, so the portal can show a summary view early and reveal full day-by-day detail — including departure-specific variance notes and select-by-date choice options — as your operations team confirms it. A version counter on the itinerary drives the live change feed, so guests see "updated 2 minutes ago" rather than a stale PDF.
The worked example
Like every Edge product, the portal is documented through Meridian Travel Co., the fictional reference tenant. Meridian's guest Elena Carter (booking MT-882401) confirms her passport with an on-device scan, completes the pre-travel form variant for her destination, pays her balance and watches the invoice regenerate instantly, while Meridian's operations team tracks her party's readiness on the dashboard. Your implementation starts from that reference configuration.
Where the data comes from
The portal is integration-first: it reads a canonical booking feed from your reservation system and emits write-back events for everything a guest or agent does. The full field-by-field integration surface is specified in Data contracts — start there for a technical review.
Where next
- Configuration — the
portal.yamlreference: portals, providers, feature flags, branding - Authentication — magic-link sign-in, session tokens, and the demo-versus-production posture
- API reference — the
/api/portal/v1surface, endpoint by endpoint - Tenant UI source — the ownership model: your React source, bundled and hosted by the platform
- Integration architecture — mock versus live providers, upstream systems, observability
- Data contracts — the canonical booking feed and write-back events