## TL;DR
A 400 for invalid event action means the payload's action field is not one of trigger, acknowledge, or resolve: usually a typo, a v1 action sent to the v2 endpoint, or a custom value the API does not accept. Send only the documented actions, validate the payload before sending, and use dedup keys so retries do not create duplicate incidents. The action vocabulary is tiny; the fix is spelling it right.

## The query

```text
pagerduty incident webhook 400: invalid event action
```

## Use this when

- PagerDuty event webhooks return 400
- Incidents fail to trigger from webhooks
- You are building PagerDuty integrations
- Migrating from Events API v1 to v2

## Not for

- On-call schedule design
- Escalation policy configuration
- Incident response runbooks
- PagerDuty pricing or plans

## Steps

### 1. Check the action value against the v2 vocabulary

The Events API v2 accepts exactly trigger, acknowledge, and resolve. Anything else 400s. Compare your payload's action character by character; typos and v1-era values are the usual culprits.

Expected output: action value matching the documented vocabulary.

### 2. Confirm you are hitting the v2 endpoint

v1 and v2 have different payload shapes and endpoints. A v1-shaped payload (or v1 action values) sent to v2 fails. Verify the endpoint URL and the payload schema version match.

Expected output: endpoint and payload schema version aligned.

### 3. Validate payloads before sending

Run outbound payloads through a schema check: required fields present, action in vocabulary, routing key valid. Pre-send validation catches the typo locally with a clear message instead of a bare 400.

Expected output: pre-send validation on every event payload.

### 4. Use dedup keys for trigger idempotency

Include a stable dedup_key so retries and duplicate sends update the same incident instead of opening new ones. Without it, a retried trigger after a 400 fix creates a duplicate incident.

Expected output: dedup keys on all trigger events.

### 5. Log the full 400 response body

PagerDuty's 400 body names the offending field. Log it on every failure; the body turns "invalid event action" from a mystery into a one-line fix. Keep the log queryable for integration debugging.

Expected output: 400 bodies logged with field-level detail.

## Template: the checklist

```text
PagerDuty event action fix:
[ ] Action value in the v2 vocabulary (trigger/acknowledge/resolve)
[ ] Endpoint version matching payload schema
[ ] Pre-send payload validation
[ ] Dedup keys on trigger events
[ ] 400 response bodies logged
```

## Variant phrasings

### pagerduty webhook 400 bad request

Steps 1 and 5. Check the action, read the body.

### invalid event action pagerduty

Step 1 as the direct fix.

### pagerduty events api v2 payload rejected

Steps 2 and 3. Version alignment plus validation.

## Why it happens

The Events API went through a v1-to-v2 migration that changed the payload shape, and integrations get built from mixed documentation: a v2 endpoint with a v1-era example, or a hand-rolled payload with a plausible-but-wrong action like "create" or "fire." The API's vocabulary is deliberately small, so almost every 400 is a vocabulary mismatch, not a deep bug.

## Edge cases

- Custom actions in change events: change events have their own schema; do not mix incident actions into them.
- Acknowledge on untriggered incidents: valid action, but nothing to acknowledge. Handle the no-op gracefully.
- Routing key versus integration key: the wrong key 400s differently. Verify which key the error names.
- Retried triggers after fixing: the dedup key prevents the retry from doubling the incident. Always include it.

## Provenance

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