Skip to main content

​
Notifizz Event Tracking SDK

Event tracking is how your backend tells Notifizz that something happened. You emit one event with a flat track(eventName, properties) call, and the Notifizz orchestrator resolves campaigns, builds recipients, and dispatches notifications across every channel — no client-side workflow or recipient targeting.

​
TL;DR

  • One call, server-side routing. client.track(eventName, properties) is the only method you need to send. Campaign matching, enrichment, and channel dispatch happen in Notifizz.
  • Three SDKs, same wire format. Node, Java, and PHP all post to POST /v1/events/track with the same payload shape.
  • Idempotency built in. Every track() call carries an idempotency key (auto-generated UUID by default, caller-supplied when retrying jobs).
  • Retries built in. Each SDK retries transient failures twice (1s, then 2s) before bubbling the error.
  • Same surface in all three. Enrichers, event declaration and schema validation modes ship in Node, Java and PHP alike (Java and PHP since 2.0.0). The only Node-specific extra is the bundled Zod re-export.

​
Available SDKs

Node.js

@notifizz/nodejs — npm package for Node and TypeScript backends. Bundles a Zod re-export for schemas.

Java / Kotlin

com.notifizz:notifizz-java — Maven Central package for JVM applications.

PHP

notifizz/php — Composer package for PHP applications.

​
Cross-language feature matrix

Schemas are the one place the three SDKs differ in shape, not in capability. Node accepts Zod (bundled and re-exported) or raw JSON Schema; Java and PHP take plain JSON Schema, with a JsonSchema fluent builder for the common cases. What travels on the wire — and what the orchestrator reads — is JSON Schema in every language.

​
Wire format

All three SDKs hit the same backend endpoint:
occurredAt is optional and omitted entirely unless you declare it — an absent field means reception time is the event time. When present it must be ISO 8601 and must not be in the future (60-second skew tolerance), or the call is refused with event/invalid-occurred-at. The full DTO and idempotency contract are in the Event Tracking reference.

​
FAQ

Use the SDK that matches your backend runtime. Since 2.0.0 on the JVM and PHP sides, the three cover the same backend surface: track(), enrichers, declareEvent(), schema modes, Audience identity, widget auth. The only remaining delta is the bundled Zod re-export, which is specific to Node — Java and PHP describe schemas as JSON Schema instead.
client.send(...) and the POST /v1/notification/.../track route were removed. The whole platform is now event-driven: emit an event, let a campaign decide the channel and the recipients. Migrating is a one-line change to client.track(eventName, properties).
Put the recipient identifiers in the event properties ({ userId, email, ... }) and let the campaign’s orchestrator resolve them — directly, via an enricher, or via a dynamic recipient source. The shape “one event per audience” is intentional: it keeps the recipient resolution server-side and traceable.
Not today. Each track() call is one event. If you need to emit many events at once, fire them in parallel from your code — the SDK retries each one independently and idempotency keys prevent duplicates.
The backend has already accepted an event with the same idempotency key. This is the success path for a retried emit — your code does not need to do anything. See the Event Tracking reference for the full response shape.
Yes. The wire format is plain HTTP+JSON — see the Event Tracking reference. Any language that can make an authenticated POST works. The SDKs only add idempotency-key generation, retries, and HMAC token helpers on top.

​
See also

Backend quickstart

Send your first event in under five minutes.

Event Tracking reference

Full HTTP wire format, idempotency contract, error shapes.

Notification Center widget

Display the notifications your events drive.

Authentication overview

Pick the right widget auth mode for your stack.