Webclat / Klaviyo Practice
Webclat / Klaviyo Practice  /  implementation

Klaviyo Events API: custom event tracking beyond the e-commerce defaults

Klaviyo's native integrations cover the standard e-commerce path well: orders, checkouts, product views. Everything else - backend status changes, product usage, non-ecommerce lifecycle events - has to be sent explicitly through the Events API, and it has to be sent with the naming and property discipline that makes flows and segments actually work.

What the Events API is for

The Events API is a direct HTTP endpoint: your backend, a webhook handler, or a queue worker posts an event with a metric name, a profile identifier, and a set of properties. No CRM or intermediary system is required - this is the "backend tracking without a CRM" pattern: your application is the source of truth, and it tells Klaviyo directly what happened.

Where custom events matter most

Business typeCustom event exampleWhy the default integration misses it
Subscription / SaaSTrial started, plan upgraded, seat added, usage threshold hitNo e-commerce order to hang the event off - it's a backend state change
Subscription boxesBox skipped, box customized, recurring charge failedRecurring-order logic differs from a standard one-time purchase
Marketplaces / multi-vendorVendor payout issued, listing approvedNot a customer-facing purchase event at all
Services / bookingsAppointment booked, appointment completed, no-showNo native e-commerce integration to source it from
Any businessSupport ticket resolved, warranty registered, loyalty tier changedBackend-only state, invisible to client-side or e-commerce tracking

Naming and property discipline

  • One event name per distinct business action - avoid overloading a single event with a "status" property to mean several different things.
  • Every property a flow or segment might filter on should be present on every instance of the event, even if the value is null/empty - missing properties fail silently, not loudly.
  • Timestamps should reflect when the action actually happened in your system, not when the API call was made, if the two can differ (e.g. batch processing, retries).
  • Idempotency: retried webhook deliveries should not create duplicate events with different timestamps.

Server-side vs. client-side

Send server-side whenever an event represents a backend truth (a payment succeeding, a subscription renewing) or when reliability matters more than latency - server-side calls aren't subject to ad blockers or JavaScript errors. Client-side remains appropriate for pure browsing signals where some loss is acceptable.

Common questions

When should an event be sent server-side vs client-side?

Server-side whenever the event represents something that happened in your backend (a subscription renewal, a support ticket closing, a loan/application status change) or when reliability matters more than latency. Client-side is fine for pure browsing/interaction signals where some loss is acceptable.

Do I need a CRM to send custom events to Klaviyo?

No. The Events API accepts a direct HTTP call from any backend system - your application server, a queue worker, a webhook handler - with no CRM in between. A CRM can be one source of events, but it isn't required.

What happens if an event is missing a required property?

Klaviyo will still record the event, but any flow filter or segment condition that references the missing property will simply not match - silently, with no error surfaced. This is why property-completeness checks matter as much as the event firing at all.

Can custom events trigger flows the same way native events do?

Yes, provided the event and its properties are structured the way the flow's trigger and filter conditions expect - see our flow architecture guide for how that mapping works.

Get a custom event spec built for your backend.

Naming, properties, and server-side vs. client-side placement - documented before anyone writes code.

Scope a Custom Event Build