inventory.duplicate.resolved is the broad fan-out event. When we close a duplicate report on hotel X, every Pro+ organization with at least one active mapping pointing at X is notified, regardless of who originally filed the duplicate.
If your downstream system caches the hotel id you mapped to, this is your signal to invalidate that cache.
When it fires
When aReferenceHotelDuplicateReport is resolved by our team. The same event id may be delivered to many subscriptions (one per receiving org).
Required plan
Pro and above.Recipients
Every organization with at least onepartner_mapping_result whose matchedReferenceHotelId is either the original or the duplicate hotel id.
Payload
Fields
| Field | Type | Notes |
|---|---|---|
data.reportId | UUID | The duplicate report that was closed. |
data.originalHotelId | UUID | The canonical reference hotel we kept. |
data.duplicateHotelId | UUID | The reference hotel that was merged or dismissed. |
data.resolution | "FIXED" | "DISMISSED" | FIXED means the duplicate was real and merged. DISMISSED means we determined the two hotels are genuinely different. |
data.resolvedAt | ISO timestamp | When the report transitioned. |
What to do
- If
resolution = FIXEDand any of your mappings point toduplicateHotelId, those mappings will be redirected tooriginalHotelIdserver-side. You should invalidate any cached reference data and consider re-fetching the mapping result. - If
resolution = DISMISSED, no mapping changes — but you may still want to record that we explicitly considered and rejected the duplicate.