Use the webhook signing secret from the provider dashboard for signature verification, not the API key. They are different credentials with different jobs: the API key authenticates your outbound calls, the signing secret verifies their inbound webhooks. Point the HMAC computation at the signing secret and verification starts passing.

```text
agent verified the webhook signature against the wrong secret  -  it used the API key instead of the webhook signing secret
```

## Steps

1. In the provider dashboard, find the webhook signing secret. It usually lives under the webhooks or endpoints section, separate from the API keys page. Confirm it is a different value from the API key.
   Expected: You have located the signing secret and confirmed it differs from the API key.

2. In the webhook handler, change the verification step to use the signing secret for the HMAC computation. Leave the API key in place for outbound API calls only - each credential keeps its own job.
   Expected: Verification uses the signing secret; outbound calls still use the API key.

3. Store the signing secret in the same secrets manager as the API key, under a clearly distinct name, so the next reader does not conflate them again.
   Expected: Both credentials are stored under distinct names with distinct purposes documented.

4. Re-send a test webhook from the provider dashboard and confirm verification passes, then confirm a normal outbound API call still authenticates with the API key.
   Expected: Signatures verify with the signing secret and outbound calls still work with the API key.

## Use this when

- signature verification fails even though raw-body handling and digest encoding are correct
- the same credential is used for API calls and webhook verification
- the dashboard shows multiple secrets and the handler may be using the wrong one

## Not for this skill when

- the digest encoding mismatches, for example hex against base64 - fix the encoding first
- the handler signs parsed JSON instead of raw bytes - fix the signed payload first
- signatures pass but timestamp checks fail - that is a tolerance problem

## Variant phrasings

### webhook wrong secret
### used API key for webhook verification
### signing secret vs API key
### webhook signature invalid secret

## Why it happens

Agents see one credential in the environment and reuse it everywhere - it is the path of least resistance and it works for outbound calls. Providers issue separate secrets on purpose: the API key travels on every outbound request, while the signing secret must stay private to prove inbound payloads really came from the provider. Using one for the other's job fails closed, which is the safe direction, but it fails on every delivery until fixed.

## Edge cases

- Providers rotate signing secrets: support a primary and secondary value during rotation windows
- Test-mode and live-mode signing secrets differ - verify against the one matching the event's mode
- Never log either credential, and never echo them into error responses
- If verification fails after rotation, check whether the dashboard shows a new secret before debugging the code

## Provenance

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