Getting changes out
Subscribe your systems to record events, delivered to an HTTPS endpoint, Amazon SQS, Amazon SNS or Kafka - signed, retried and logged.
Push, don't poll
When a record changes, your other systems can be told rather than having to ask. Subscribe an endpoint of yours to the events you care about, and deliveries arrive signed, retried, and logged.
Webhooks are enabled per schema, so you opt in the record types that matter instead of receiving everything.
What you can subscribe to
| Event | Fires when |
|---|---|
entity.created | A record is created |
entity.updated | A record is updated — the payload carries a field-level difference |
entity.deleted | A record is soft-deleted |
entity.version_promoted | A record is promoted to a new version |
The field-level difference on updates is the one to build against: a consumer can see what actually changed without re-reading the whole record and diffing it itself.
Where deliveries go
Four destinations, so you can usually avoid standing up a receiver:
- An HTTPS endpoint of yours
- Amazon SQS
- Amazon SNS
- Kafka
A note on direction, because it is easy to get backwards: SQS, SNS and Kafka here are destinations for events leaving the product. They are not ways to send data in. To push data in, use the REST API or the bulk endpoints — see The generated API.
Verifying a delivery is genuine
Payloads are signed. Verify the signature before acting on a delivery — an endpoint that accepts anything posted to it is an endpoint anyone can drive.
When delivery fails
Failures retry on a backoff and then dead-letter. You are not left guessing about any of it:
- A delivery log records every attempt, with per-attempt detail and aggregate statistics.
- Bulk redrive from the console replays what dead-lettered, once the receiving end is healthy again.
- Alerts by email and in-app fire when deliveries dead-letter, or when the failure rate crosses a threshold.
Build your receiver to tolerate being called more than once with the same event. Retries mean at-least-once delivery, so make the handler idempotent — key on the event's identifier and ignore one you have already processed.
Events on the stream
Separately from your own subscriptions, record and schema changes are published to the platform event stream. The property worth knowing: the event is written in the same transaction as the data change, then dispatched. The two cannot drift — if the write succeeded, the event exists.
Sensitive field values are replaced before an event leaves the service, while the field name is kept, so filters that check whether a field is present still work.
A working pattern
For keeping a downstream system in step:
- Enable webhooks on the schema, subscribe to
created,updatedanddeleted. - Verify the signature on arrival; reject anything that fails.
- Deduplicate on the event identifier.
- Apply the field-level difference rather than re-fetching.
- Watch the delivery log for the first week, and set the failure-rate alert lower than you think you need.
Where to go next
- The generated API — reading and writing records directly.
- Connecting a system to a workflow — reacting to a record event with a whole process rather than a single call.