docs: explain native webhook signature verification

[Sealdot]

Problem

Webhook consumers can calculate a different digest by signing only the body, reserializing JSON, or using an API/contact identity token instead of the source's webhook signing secret. The API introduction does not currently link to a receiver verification guide.

Related: chatwoot/chatwoot#13809. This documentation change does not claim to fix or close that report.

Solution

Add a webhook verification guide to API Reference navigation and link it from the API introduction. Include a standard-library Python example, the timestamp-plus-original-body signing input, source-specific secrets, and separate replay/idempotency guidance.

Key decisions

• Scope source mappings explicitly to v4.17.1, with links to both listeners and the signing implementation; older installations may differ.
• Label the example's age/skew window as receiver policy.
• Explain that the delivery header is outside the signed input and is not an authenticated logical-event identity.
• Keep this contribution limited to documentation; no provider or customer-service behavior changes.

Tests

• Extracted and executed the Python code block: 19 checks covering a valid UTF-8/newline body, tampering, wrong key/timestamp, age/skew boundaries, and malformed headers.
• Verified a fixed signature independently generated by Ruby OpenSSL using the upstream signing expression.
• Parsed docs.json and checked the navigation target; git diff --check passed.

Risks

Mintlify rendering and its broken-links command were not run locally; no Node packages were installed. No live Chatwoot instance was used.

The first CI run failed during npm i -g mint with ETARGET: No matching version found for @mintlify/cli@4.0.1520. It did not reach the broken-link check. This remains a draft pending a working documentation tool installation, preview and maintainer review; the workflow is unchanged by this PR.

The registry subsequently returned metadata for that version, but rerunning the workflow was denied with “Must have admin rights to Repository.” A maintainer rerun is needed to determine whether installation now succeeds.

Follow-up

Review the generated documentation preview and any wording needed for version-specific secret retrieval before marking ready.

[Sealdot]

Could a maintainer rerun the Broken Link Check when convenient? The first run stopped at npm i -g mint with ETARGET for @mintlify/cli@4.0.1520, before checking documentation. A subsequent registry lookup returned that version, but my attempt to rerun was denied because it requires repository admin rights.

The workflow is unchanged in this PR. The extracted Python example passed 19 local checks, including an independent Ruby OpenSSL signature vector. I am keeping the PR in draft pending the check and documentation preview.