This page is intentionally text-only because demo2 has no configured outbound flow or sync contract whose screenshot would prove the behavior below. An empty Sync Profiles register is not evidence of entity-event payloads, connector delivery, retry or loop suppression.
Outbound movement is authored as a flow delivered through a connector. xMatix does not expose a self-service outbound callback registry where third parties add arbitrary subscription URLs; administrators configure the target connection, trigger and flow. This is narrower than saying the platform has no webhook subsystem: Integration Hub has anonymous inbound webhook endpoints and Webhook triggers, including optional HMAC validation and durable ingress recovery.
There are three outbound shapes, and choosing between them is most of the design work.
Shape 1: entity-event flows — push on change
An entity-event trigger fires a flow when records of an entity are created, updated or deleted. This is the push-style tool: a record is saved, and seconds later a flow is running with that record's identity in hand — typically fetching the full record, mapping it, and writing it to the external system through a connector.
The properties that matter:
- The business write commits first. Trigger failures cannot roll it back or surface as a business-save failure. The post-save handler still performs trigger lookup and queues work after commit, so avoid promising zero response-time overhead; the potentially long flow dispatch is fire-and-forget on a fresh scope.
- The trigger payload is thin—entity, operation and record id. It does not automatically fetch the record. Add an explicit entity-read/source step when the outbound payload needs current fields, and decide what Delete should send because the row may no longer be readable.
- Loop suppression is origin-specific. Entity writes made by an entity-event-originated run are suppressed from firing more entity-event triggers, including across its queue boundary. Scheduled, inbound-webhook and manual runs are deliberately allowed to cascade into entity-event flows, so design and test those chains for bounded behavior.
- You can scope the trigger to specific operations (for example Create and Update but not Delete).
If the requirement reads "call the partner's API whenever an order changes", this is the shape — with the partner-specific connector, or the generic HTTP/REST connector when the target is an arbitrary API endpoint.
Shape 2: scheduled outbound flows — push on cadence
A schedule trigger runs an outbound flow on a cron cadence: read the xMatix records in scope (filtered as needed), map, and write out in batches. This fits targets that want feeds rather than events — nightly exports, hourly batch upserts, systems that rate-limit per call and prefer 200 records at once. Batch-capable connectors (Salesforce) report per-record results, so one bad record fails alone rather than sinking the batch.
Shape 3: outbound sync — a standing contract
When the need is "that system should continuously reflect these entities", stop authoring flows and declare a sync profile with outbound (or bidirectional) entities. The profile compiles the flows itself and adds what hand-authored pushes lack: watermark cursors so each cycle sends only what changed, a per-record ledger pairing xMatix records with their external counterparts, echo suppression so nothing ping-pongs, and conflict handling when the other side edited too.
Delivery, retries and idempotency
Outbound runs inherit the integration runtime's failure handling: transient faults can retry with backoff and deterministic faults wait for a fix. Manual replay is limited to Failed, Succeeded, DeadLettered and Rejected runs. It requires a surviving flow definition with an active version and either an explicit request body or retained archived InputJson; it runs through the currently active version rather than resurrecting an immutable old executor. Because delivery can repeat after ambiguous timeouts, design the destination for stable-key idempotency.
Rapid successive edits to the same record dispatch independent runs, so strict cross-run ordering should not be assumed — another reason keyed upserts (last write of the current state) beat "create a new row per event" designs.
Common questions
Can an external system be notified the instant something changes in xMatix?
Effectively yes: an entity-event flow fires on save and delivers within seconds through whatever connector you point it at. What xMatix does not offer is self-service subscriptions — the notification is an admin-authored flow inside xMatix, not a URL the external party registers themselves. In practice that is the governance difference, not a latency difference.
Can xMatix POST to an arbitrary URL?
Yes — the generic HTTP/REST connector takes a URL, headers (including secret-referenced auth) and a payload your flow constructs, used as the sink of an entity-event or scheduled flow. The URL is part of reviewed connection configuration, held by the integration app.
What happens when the target system is down?
The business record is already committed before dispatch, so a connector failure does not roll it back. The integration side records or logs the failed dispatch, retries eligible transient categories and dead-letters exhausted work. After recovery, replay only an eligible terminal run with retained input and a valid active flow version, or let a sync profile retry from the cursor that did not advance past uncommitted work.
Should I push deletes?
Cautiously. Entity-event triggers can fire on Delete, and sync entities have delete modes — but the default everywhere is not to propagate deletion, because a wrong delete is the one mistake the other system cannot un-make. Prefer status fields ("cancelled", "inactive") that sync as ordinary updates, and reserve true delete propagation for pairs of systems where you have thought through recovery.