More Precise Outcome Codes Across Integrations
The June observability update gave delivery attempts a shared outcome-code vocabulary across integrations. This follow-up makes those codes more precise in cases that were still too broad, so failed deliveries are easier to triage from the event detail page and API.
More specific failed-attempt labels
Several destination responses now land on more specific outcome codes. A throttled request reports rate_limited, a missing destination record reports destination_not_found, invalid mapped fields report validation_failed, and expired credentials report auth_failed.
That precision makes it easier to compare delivery behavior across a workspace. Support teams can answer why a customer-facing integration failed, and product teams can build dashboards or alerts around actionable outcomes instead of broad error categories.
Clearer destination responses
Common destination responses that previously appeared as broad client errors now report more specific outcomes, so the event detail page points closer to the action needed: fix a field value, reconnect credentials, retry after throttling, or update a missing destination reference.
The result is less guesswork when reviewing failed attempts. The attempt history shows the delivery status, the outcome code, and the destination response details where available, so a rejected event can be triaged from the dashboard or API without reproducing the delivery first.
For API consumers
The outcome-code enum remains additive from the June observability release. Existing clients that already handle the published values do not need a schema change, but clients that group errors by destination should see more failed attempts land in the most specific available category.