Webinar Integration

This guide is for developers who want to connect webinar tools with KlickTipp.

These integrations usually have the same business goal: register contacts, store webinar metadata, track attendance and replay behavior, assign the correct tags, and trigger follow-up campaigns without corrupting state when events arrive late or more than once.

Use the Listbuilding API only for a very simple registration flow with one fixed tag path and no later attendance-state updates.

Use the Management API for most webinar integrations because registration, attendance, replay, no-show, and buyer events all require dynamic contact updates and tag changes.

This guide applies to webinar tools in general. It uses the following platforms as implementation examples because current KlickTipp templates already exist for them:

• WebinarJam
• Zoom
• EverWebinar

Most webinar tools can produce the same logical event family:

• registration
• live attendance
• full live attendance
• no-show
• replay attendance
• full replay attendance
• purchase during or after the webinar
• correction events that arrive later than the first attendance result

Before you import templates or activate webhooks, create the required custom fields and tags in KlickTipp.

These fields are useful for all webinar integrations:

• webinar choice or webinar identifier
• webinar start timestamp
• join URL
• registration identifier
• attendance duration or replay duration when the platform provides it

The current templates for the example platforms use fields like these:

When storing these values, make sure the configured field types match the payload values. For field-type details, see Data Field Types and Input Formats.

Use the following model as the default mapping between webinar events and KlickTipp operations.

Use stable, explicit tags that make the contact state readable to support, campaign, and automation teams.

Recommended logical states:

• [Tool] [Webinar] Registered
• [Tool] [Webinar] Attended Live
• [Tool] [Webinar] Fully Attended Live
• [Tool] [Webinar] Did Not Attend Live
• [Tool] [Webinar] Attended Replay
• [Tool] [Webinar] Fully Attended Replay
• [Tool] [Webinar] Purchased Live
• [Tool] [Webinar] Purchased Replay

Template sets often use webinar-specific names such as Beginners and Experts. Keep those names if the webinar platform routes to different webinar IDs or different campaigns.

The integration should treat attendance and purchase updates as state transitions, not as isolated one-off tags.

1. Registered
2. Attended Live or Did Not Attend Live
3. optional Fully Attended Live
4. optional Attended Replay if the contact missed or partially watched the live webinar
5. optional Fully Attended Replay
6. optional Purchased Live or Purchased Replay

• Fully Attended Live implies Attended Live.
• Fully Attended Replay implies Attended Replay.
• Purchased Live and Purchased Replay are commercial states, not attendance replacements.
• Did Not Attend Live conflicts with Attended Live and Fully Attended Live.
• Replay participation does not erase a previous live-attendance state.
• A replay purchase does not erase a live purchase unless your business model explicitly requires a single buyer tag.

Use these default rules when events disagree:

Webinar platforms can deliver events out of order. Your integration must therefore separate event arrival order from business truth.

Process events like this:

1. Identify the contact by email address.
2. Identify the webinar instance by webinar ID, meeting ID, or another stable webinar key.
3. Compare the incoming event with the current stored state for that contact and webinar.
4. Apply only the state transition that makes the contact more correct, not merely newer by arrival time.
5. Remove obsolete conflicting tags when the new event is authoritative.

Examples:

• A contact may first receive Did Not Attend Live because the attendance job ran before delayed attendance data was available.
• A contact may later receive Attended Live after the platform finishes processing attendance.
• A buyer event can arrive before or after attendance data.

The integration should treat these as normal correction flows, not as fatal errors.

For webinar integrations, the email address is the primary contact identifier. The webinar identifier and event type form the business key for processing.

Recommended idempotency rules:

• Repeated Add or Update Contact calls with the same email must update the existing contact.
• Repeated Tag Contact calls for the same tag should be safe.
• Repeated Untag Contact calls for a tag that is already absent should be safe.
• Store a processed-event key such as platform + webinar_id + contact_email + event_type + source_event_id when the platform provides a stable event ID.
• If the platform does not provide a stable event ID, derive a deterministic key from the event payload and processing window.

Do not assume that duplicate delivery means duplicate intent. Registration, attendance, replay, and purchase events are often retried by the source platform or the iPaaS template.

Retries should happen only for technical failures, not for business-rule conflicts.

Retry these cases:

• transient network failures
• webhook timeout between the platform and your middleware
• temporary API unavailability
• rate limiting

Do not blindly retry these cases:

• missing required email address
• unknown webinar mapping
• invalid field type for a custom field
• contradictory attendance data without a clear winning rule

Recommended retry model:

1. Validate the payload before calling KlickTipp.
2. Retry transient failures with backoff.
3. Stop automatic retries after a bounded number of attempts.
4. Move unresolved cases to manual review with the raw event payload and the current tag state.

Some cases should not be auto-resolved:

• the contact email is missing or invalid
• the webinar choice does not map to a known webinar ID
• the same contact appears under conflicting emails
• a no-show and a full-attendance result both arrive with equally strong evidence
• duration data is missing but the template logic depends on duration thresholds
• a buyer event cannot be tied safely to a live or replay session

Mark these contacts for manual review instead of guessing.

1. Create the required data fields and tags in KlickTipp.
2. Create or identify the webinar landing page or form in KlickTipp.
3. Configure the outbound webhook or iPaaS trigger.
4. Load setup data with List Opt-in Processes, List Tags, and List Data Fields.
5. Receive the registration event.
6. Validate email, webinar mapping, and required field values.
7. Create or update the contact with Add or Update Contact.
8. Apply the registration tag with Tag Contact.
9. Persist the mapping between contact, webinar, and source-platform registration ID.
10. Receive later attendance, replay, or purchase events.
11. Reconcile the state using the tag state machine.
12. Add the correct tags and remove obsolete conflicting tags.
13. Retry technical failures with backoff.
14. Route unresolved conflicts to manual review.

The current template family for WebinarJam uses separate flows for:

• registration import
• live-attendance tagging
• replay-attendance tagging
• purchaser tagging

Typical data written back to KlickTipp:

• webinar selection
• webinar start
• live-room URL
• replay URL

Typical logic:

• route by webinar type such as Beginners and Experts
• tag live attendance
• tag replay attendance
• tag buyers differently depending on whether the purchase happened live or after replay

The current template family for Zoom uses separate flows for:

• registration
• webinar attendance tagging
• meeting attendance tagging

Typical data written back to KlickTipp:

• webinar selection
• webinar start
• join URL
• registration ID
• duration

Typical logic:

• route by webinar or meeting topic
• calculate participation from attendance duration
• assign separate tags for attended, fully attended, and not attended

The current template family for EverWebinar uses separate flows for:

• registration
• live-attendance tagging
• replay-attendance tagging
• purchaser tagging

Typical data written back to KlickTipp:

• webinar selection
• webinar start
• live-room URL
• replay URL

Typical logic:

• route by webinar type
• distinguish live attendance from replay attendance
• distinguish live purchase from replay purchase
• apply a stronger full-attendance tag when the platform-specific attendance threshold is met

1. A contact submits a KlickTipp landing page form for Zoom Beginners.
2. The integration registers the contact in Zoom.
3. The integration writes Zoom_Webinar_selection, Zoom_Webinar_Start, Zoom_Join_URL, and Zoom_Registration_ID.
4. The integration tags the contact with Zoom Beginners Registered.
5. After the webinar ends, the attendance workflow checks the participant duration.
6. The integration tags Zoom Beginners Attended Live.
7. If the full-attendance threshold is met, the integration also tags Zoom Beginners Fully Attended Live.
8. If Did Not Attend Live was set earlier by a stale event, remove it.

1. A contact registers for an EverWebinar session.
2. The first attendance reconciliation marks the contact as Did Not Attend Live.
3. The contact later watches the replay.
4. The replay workflow tags Attended Replay.
5. If the replay threshold is met, tag Fully Attended Replay.
6. Keep the no-show-live tag because it still correctly describes the live session.

1. A WebinarJam attendance job runs too early and sets Did Not Attend Live.
2. A later platform event includes valid live-attendance time stamps.
3. The integration recognizes that live attendance is the stronger state.
4. The integration adds Attended Live.
5. The integration removes Did Not Attend Live.
6. If the duration threshold is met, add Fully Attended Live.

1. A contact registers for a webinar.
2. A buyer event arrives before the attendance reconciliation job finishes.
3. The integration tags Purchased Live or Purchased Replay if the source event makes that clear.
4. The attendance state is updated later when the attendance data arrives.
5. Purchase tags remain in place because they represent a separate business outcome.

• Use the Management API for event-based webinar flows.
• Keep the contact identity stable by email address.
• Keep webinar identity stable by webinar ID, meeting ID, or another deterministic webinar key.
• Separate attendance state tags from purchase state tags.
• Treat delayed correction events as normal.
• Make retries technical, not semantic.
• Use manual review when business truth cannot be derived safely.

Reliable webinar integrations need more than contact creation.

Whether the source platform is WebinarJam, Zoom, EverWebinar, or another webinar tool, the integration should map registration, attendance, replay, and purchase events to deterministic KlickTipp updates, apply a clear tag state machine, resolve out-of-order events safely, retry technical failures carefully, and preserve enough webinar metadata to drive reminders and follow-up campaigns correctly.