Lead Portal
The lead portal is a hosted, lead-facing booking surface at portal.rocketlead.io. Automations mint a personal link per lead; the lead opens it (typically from a WhatsApp or email message), picks a location and time, and books an appointment that lands directly on their existing lead entry — no duplicate entries, no form submission.
The portal is not part of the Connect API. Its backing endpoints are an internal surface consumed only by the portal app itself; the integration points for developers are the portal.link.mint automation node and the standard automation triggers that fire on portal bookings.
Link lifecycle
Section titled “Link lifecycle”A portal link has the shape:
https://portal.rocketlead.io/<token>The link is the sole credential — a personal invitation, not a public URL. There is no login, cookie, or session on top of it.
| Property | Behavior |
|---|---|
| Validity | 60 days from creation (fixed for now; will become an org setting) |
| Reuse | A link books once. After booking it resolves to the confirmation screen only |
| Revocation | Links can be revoked server-side at any time |
| Retries | A retried automation step re-sends the same link — duplicate sends never carry different links |
| Dead links | Unknown links show a generic dead-link screen; expired and revoked links reveal nothing — no lead data, no locations, no offering |
What a link offers
Section titled “What a link offers”What a link can do and where it can book is fixed when it is created, from the selection made in the automation node:
- Capabilities — currently
book(book an appointment onto the existing lead). Rescheduling, cancelling, and contact-detail editing are planned; a multi-capability link opens on a menu, a book-only link jumps straight into the booking flow. - Locations and appointment types — chosen in the node, with
allwildcards that also cover locations/types created later (they apply per link creation). - Routing — never configured anywhere. The platform resolves what is actually bookable at the selected locations from the same data the form widget uses, and merges availability when an appointment type is bookable through several calendars.
Automation-minted links are personal invitations: they offer all bookable slot windows, including ones not released for public booking via forms.
Links are snapshots
Section titled “Links are snapshots”A link never changes after creation. Editing portal settings, locations, or appointment types affects only newly created links — outstanding links keep offering what they were minted with until they expire. To retract a link, revoke it (or let it expire) and send a new one.
Booking window
Section titled “Booking window”| Setting | Default | Range |
|---|---|---|
| Booking horizon | 30 days | 1–365 days |
| Minimum notice | 3 hours | 0–720 hours |
Org-wide defaults live in the portal settings (console → Einstellungen → Lead-Portal); each automation node can override them for the links it creates.
Security properties
Section titled “Security properties”- Links cannot be reconstructed from stored data — only a hash is kept.
- Expired and revoked links are informationally dead: they expose no personal data.
- Calendar exports (
termin.ics, Google Calendar) never contain the link itself. - If a link cannot be created (misconfigured selection, deleted lead), the automation run fails before any send node executes — a dead link is never delivered. See Minting.
Interplay with automations
Section titled “Interplay with automations”A portal booking is a regular platform booking: it appears in the calendar and the lead’s file, and fires calendar.appointment.booked — downstream automations (confirmations, reminders, lead-state changes) run exactly as for a booking made in the console.