For platforms & partners

Attendance as a layer you can call.

You already own registration. ewent adds the part that happens between registration and the door — per-attendee checklists, timezone-local cadence, signed links — behind an API you can wire up in an afternoon.

The shape of it

Overlay, not replacement.

Nothing about your product moves. You keep the ticket, the payment, the attendee record and the relationship. ewent receives the minimum it needs to run a cadence and hands back a signed URL you can put anywhere.

your platform                     ewent
─────────────                     ─────
registration created   ──POST──▶  create event + attendee
                       ◀──────    signed checklist URL
                                  │
render URL in your UI  ◀──────────┘
   or let us email it              cadence runs (8 touchpoints,
                                   attendee-local scheduling)
                       ◀──webhook  ticks, opens, cancellations
Two integration depths. Hand us the attendee and let ewent send the mail, or take the signed URL and send everything yourself from your own domain. Most partners start with the first and move to the second.

Three calls

The whole integration.

# 1 — create the event (once per occurrence)
curl -X POST https://ewent.ai/api/occurrence_create \
  -H 'Authorization: Bearer $EWENT_KEY' \
  -d 'title=Quarterly Summit&start=2026-11-04T09:00:00Z&timezone=Europe/Berlin'

# 2 — attach an attendee (once per registration)
curl -X POST https://ewent.ai/api/rsvp_create \
  -H 'Authorization: Bearer $EWENT_KEY' \
  -d 'ewent_token=$TOKEN&[email protected]&name=Ada&timezone=Europe/London'
# → { "rsvp_token": "...", "checklist_url": "https://ewent.ai/event/.../..." }

# 3 — set the checklist (once per event, or from a template)
curl -X POST https://ewent.ai/api/steps_set \
  -H 'Authorization: Bearer $EWENT_KEY' \
  -d 'ewent_token=$TOKEN&steps=[{"phase":"prep","title":"Book your hotel","url":"..."}]'
Status. The endpoints above are live in production and carry real traffic. The public reference and key self-service are still being written — see API reference for what is documented so far. Until key issuance is self-serve, ask us and we will set you up by hand.

Why partners take it

The metric your customers complain about.

↑

Show rate is your renewal story

Organizers don't churn because registration was hard. They churn because the room was half empty.

◷

Timezone logic is thankless

Per-attendee local scheduling is a genuinely annoying thing to build and maintain. It is already built.

◫

Embed, don't rebuild

The checklist ships as a drop-in widget if you'd rather render it inside your own product than link out.

Partner questions

Whose brand do attendees see?

The organizer's, then yours. ewent is deliberately invisible in the attendee experience — that is the point of an infrastructure layer.

Who is the data controller?

You or your customer, depending on your arrangement. ewent acts as processor. The DPA and subprocessor list set this out.

Can we white-label the sending domain?

That is the second integration depth — you take the signed URL and send from your own infrastructure. Talk to us about which fits.

What are the rate limits?

Documented alongside the endpoints as the reference is published. In practice nothing in this workload is high-frequency: one call per registration, one per event.

Is there a sandbox?

Not self-serve yet. We will provision a test event and key on request.

Add attendance to your platform.

Three calls, no migration for your customers, and the timezone logic already solved.