## TL;DR
"Endpoint secret invalid" means the secret your sender uses to sign requests does not match the secret Cognigy expects: a rotation happened on one side only, or the value was copied wrong. Sync them deliberately: set the same secret on both sides in one change, verify with a test request, and build rotation as a two-phase process (add new, remove old) so there is never a moment of mismatch.

## The query

```text
cognigy "endpoint secret invalid" webhook error
```

## Use this when

- Webhooks fail with invalid secret errors
- Event delivery stops after a secret change
- You are rotating webhook secrets
- Debugging webhook authentication

## Not for

- Designing Cognigy flows
- Training NLU models
- Choosing webhook versus polling
- Endpoint URL design

## Steps

### 1. Confirm which side changed last

Check the secret's change history on both sides: Cognigy config and the sender. The mismatch is always a change applied to one side only. Knowing which side moved tells you which side to fix.

Expected output: the diverged side identified.

### 2. Set the same secret on both sides in one change

Update both configurations together, treating it as a single atomic change. Sequential updates with a gap in between are how mismatches are born. One change, both sides, verified immediately.

Expected output: secrets matching on both sides.

### 3. Verify with a signed test request

Send a test webhook signed with the new secret and confirm Cognigy accepts it before declaring victory. Verification catches copy errors (trailing whitespace, wrong field) that visual inspection misses.

Expected output: a passing signed test request.

### 4. Rotate in two phases from now on

Phase one: add the new secret as accepted alongside the old. Phase two, after all senders migrated: remove the old. Two-phase rotation means there is never a moment when a legitimate sender is rejected.

Expected output: a two-phase rotation procedure documented and used.

### 5. Store secrets in a secret manager, not in chat or docs

Webhook secrets pasted into tickets, docs, or chat get copied wrong and leak. A secret manager is the single source of truth both sides read from. Copy errors disappear when nothing is copied by hand.

Expected output: secrets sourced from a manager on both sides.

## Template: the checklist

```text
Webhook secret sync:
[ ] Diverged side identified from change history
[ ] Secret set identically on both sides at once
[ ] Signed test request verified
[ ] Two-phase rotation procedure in place
[ ] Secrets stored in a manager, never pasted
```

## Variant phrasings

### cognigy webhook secret mismatch

Steps 1 and 2. Find the divergence, sync atomically.

### endpoint secret invalid after rotation

Step 4. Two-phase rotation going forward.

### webhook signature verification failing

Steps 2 and 3. Sync, then verify with a test.

## Why it happens

Secrets are shared configuration with no built-in synchronization: two systems must hold the same value, and nothing enforces it except process. Rotations, environment promotions, and manual edits change one side constantly. The invalid-secret error is the system detecting the divergence; the process gap is what created it.

## Edge cases

- Multiple senders sharing one endpoint: rotate all senders before removing the old secret. Inventory senders first.
- Secrets with special characters: encoding differences (URL encoding, escaping) can corrupt on copy. Prefer manager-sourced values.
- Staging versus production secrets: keep them distinct; a staging secret in production config fails exactly this way.
- Clock skew on timestamped signatures: if signatures include timestamps, skew can look like a secret failure. Check clocks too.

## Provenance

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