## TL;DR
Slack returned HTTP 200 with an error inside the JSON body, and the agent treated it as success. Parse the ok field on every response and treat ok false as a failure with retry and alerting.

## The query
```text
agent's slack ticket-creation webhook failed silently: 200-with-error payload
```

## Use this when
- tickets never created despite 200 responses
- the webhook log shows success but nothing happens
- Slack API errors hide inside 200s

## Not for
- webhook authentication failures
- Slack outage
- message formatting problems

## Steps
1. Inspect a recent webhook response body to confirm the error-inside-200 pattern. Expected output: the ok false payload is visible.
2. Change the agent to parse the response JSON and check the ok field. Expected output: failures are detected.
3. Retry with backoff on retriable errors and alert on permanent ones. Expected output: transient errors self-heal.
4. Log the full error payload for debugging. Expected output: the real error is diagnosable.
5. Add a reconciliation check: confirm the ticket exists after creation. Expected output: silent failures become impossible.

## Applies to
Slack webhooks and Web API, ticket-creation agents, any JSON API with 200-with-error semantics.

## Variant phrasings
### Rate limited inside a 200
Honor the retry headers in the body, not just HTTP headers.

### Error only for certain channels
The bot may lack access to specific channels; check membership.

## Why it happens
Slack signals many errors in the body while returning 200. Status-code-only checks declare victory on failures.

## Edge cases
- Test with an invalid channel to see the failure path.
- Reconciliation is the backstop; run it on a schedule too.
- Version-pin the Slack API behavior you code against.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_sKQ_feq2TuBBcURZBLPn9w