Event types

Outbound events (the envelope) carry a stable type. When you register an endpoint you choose which types it receives.

Catalogue

Type	Status	Fires when	Typical use
experience.goal.reached	Available	The flow reaches its goal.	Mark success; hand back to your systems.
experience.started	Coming	A person enters an experience.	Note engagement; start your own timer.
experience.step.completed	Coming	A flow step / card is completed.	Track progress through the flow.
experience.ended	Coming	The experience ends (goal or fail).	Close the loop; clean up.

More types are added over time. Subscribe only to what you handle; ignore types you don’t recognise.

Naming

Types are dot-namespaced and lower-case: domain.thing.happened. The domain today is experience. New domains may appear (for example, integration-specific ones) — match on the full string.

Versioning rule

The catalogue and the envelope follow an additive-only rule within a version:

• Additive (no version bump): new event types; new optional fields in data.
• Breaking (new version): removing or renaming a field, changing a field’s meaning or type, or changing when an existing type fires.

Build defensively so additive changes never break you:

• Ignore unknown event types and unknown fields.
• Don’t depend on field order or on the absence of a field.
• Branch on type (and, where present, a version marker), not on payload shape.

Reference is a contract

Because these types are published, they’re public commitments. We treat a change to them as an API change, governed by the rule above.

Related

• The body these arrive in: outbound envelope.
• Verifying them: inbound signing & verification.
• Where they’re chosen: register an endpoint.