Skip to main content
Fire emits three types of store events. Your system should handle all three:

​
store.updated

Emitted whenever a single store changes. The payload contains the full store and channel configuration.
Your endpoint receives:
The data object is ready to be forwarded. No additional Fire API calls needed. See store.updated for the full schema.
1

Verify the signature

Validate X-Fire-Signature. See Authentication.
2

Acknowledge immediately

Return 200 OK before doing any work.
3

Update downstream

Pass data to your downstream system. The payload is self-contained — no transformation required.

​
store.deleted

Emitted when a store is explicitly removed from Fire. This is the only way Fire signals a store deletion — there is no ambiguity.
Your endpoint receives:
Use storeId and storeChannels to identify and remove the store in each downstream system. See store.deleted for the full schema.

​
stores.sync

Emitted when Fire needs to propagate many stores at once — during initial onboarding or after a mass configuration change. Fire splits large batches automatically (up to 50 stores per event) and emits them sequentially.
Your endpoint receives:
Process each batch independently. Use batchIndex and batchTotal to track progress if your system needs to know when the full sync is complete. Each batch is retried independently on failure. See stores.sync for the full schema.

​
Idempotency

You may receive the same event more than once due to retries. Make your processing idempotent — handling the same event twice should produce the same result.