docs: update webhooks payload for M1 wire contract changes [OD-702]

The M1 wire contract changed after this page was approved
(outbound-hooks#15, codacy-events#260):

- Drop the X-Codacy-Timestamp header. The signature covers only the
  body, so an unsigned timestamp header could be replayed or altered
  without detection.
- Body timestamp is now an ISO 8601 UTC string, second precision, not
  a Unix timestamp. It's covered by the signature.
- Add the body status field (success, partial_success, failure) and
  note that failed and partially failed analyses fire the event too.
- Document the real retry behavior: a 5xx or timeout retries up to 2
  more times (200 ms, 400 ms delay), a 4xx drops immediately, and a
  retry reuses the same X-Codacy-Delivery value.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Author: claudiacodacy

docs/organizations/integrations/webhooks.md

@@ -42,15 +42,16 @@ Codacy sends the `quality.analysis.completed` event to every webhook endpoint of
 -   **A branch analysis finishes.** Codacy finished analyzing the newest commit of an enabled branch. Only the newest commit on a branch triggers a delivery, and reanalyzing that commit sends a new delivery.
 -   **A pull request analysis finishes.**
 
+Codacy sends the event regardless of the analysis outcome, not only when it succeeds. Check the body's `status` field for the outcome.
+
 ## Delivery payload {: id="delivery-payload"}
 
 Each delivery is an HTTP `POST` request with a JSON body and these headers:
 
 | Header | Description |
 |---|---|
 | `X-Codacy-Event` | The event type, always `quality.analysis.completed`. |
-| `X-Codacy-Delivery` | A UUID that uniquely identifies this delivery. A reanalysis of the same commit generates a new UUID. |
-| `X-Codacy-Timestamp` | The time Codacy sent the delivery, as a Unix timestamp in seconds. |
+| `X-Codacy-Delivery` | A UUID that uniquely identifies this delivery. A reanalysis of the same commit generates a new UUID, but a retry of the same delivery reuses it — see [delivery behavior](#delivery-behavior). |
 | `X-Codacy-Signature` | The [HMAC-SHA256 signature](#verifying-a-delivery) of the request body, in the form `sha256=<hex-encoded hash>`. |
 
 The body identifies the organization, the repository, the commit, and either the branch or the pull request. It doesn't include the analysis results.
@@ -64,7 +65,8 @@ Branch analysis finished:
   "repository": { "name": "engine" },
   "target": { "type": "branch", "value": "master" },
   "commitSha": "a1b2c3d4e5f60718293a4b5c6d7e8f9012345678",
-  "timestamp": 1758150000
+  "status": "success",
+  "timestamp": "2025-09-17T23:00:00Z"
 }
 ```
 
@@ -77,13 +79,15 @@ Pull request analysis finished:
   "repository": { "name": "engine" },
   "target": { "type": "pullRequest", "value": "464" },
   "commitSha": "a1b2c3d4e5f60718293a4b5c6d7e8f9012345678",
-  "timestamp": 1758150000
+  "status": "success",
+  "timestamp": "2025-09-17T23:00:00Z"
 }
 ```
 
 -   **`target.type`** is `branch` for a branch analysis or `pullRequest` for a pull request analysis. `target.value` is always a string — the branch name, or the pull request number.
 -   **`organization.provider`** is the Git provider short code: `gh` for GitHub, `gl` for GitLab, or `bb` for Bitbucket.
--   **`timestamp`** is a Unix timestamp in seconds, matching the `X-Codacy-Timestamp` header.
+-   **`status`** is `success`, `partial_success`, or `failure` — whether all, some, or none of the analysis tasks completed.
+-   **`timestamp`** is when Codacy sent the delivery, as an ISO 8601 UTC timestamp to the second (`2025-09-17T23:00:00Z`). There's no separate timestamp header: the signature covers the whole body, so verify this field instead of a header if you need to reject stale deliveries.
 
 Codacy doesn't include an issue list or a link to the analysis result in the payload. Use the [Codacy API](../../codacy-api/using-the-codacy-api.md) to look up the analysis details for the commit or pull request.
 
@@ -94,11 +98,13 @@ Verify that a delivery came from Codacy by recomputing its signature and compari
 1.  Compute the HMAC-SHA256 hash of the raw request body, using the endpoint's signing secret as the key.
 1.  Hex-encode the hash and prefix it with `sha256=`.
 1.  Compare the result to the `X-Codacy-Signature` header using a constant-time comparison, and reject the delivery if they don't match.
+1.  Optionally reject a delivery whose body `timestamp` is too old, to guard against a captured delivery being replayed.
 
 ## Delivery behavior {: id="delivery-behavior"}
 
--   Codacy waits 10 seconds for your endpoint to respond. A timeout or a non-2xx response drops the delivery — Codacy doesn't retry it.
--   Codacy can send more than one delivery for the same commit, for example after a reanalysis. Each delivery has a distinct `X-Codacy-Delivery` value, so if you need to avoid processing the same commit twice, treat deliveries with the same `commitSha` as duplicates instead.
+-   Codacy waits 10 seconds for your endpoint to respond. A `5xx` response or a timeout is retried up to 2 more times, waiting 200 ms before the first retry and 400 ms before the second. A `4xx` response drops the delivery immediately, without a retry.
+-   A retry reuses the same `X-Codacy-Delivery` value as the original attempt, so treat retries with the same value as duplicates.
+-   Codacy can also send more than one delivery for the same commit for other reasons, for example a reanalysis. Each of those deliveries has a distinct `X-Codacy-Delivery` value, so if you need to avoid processing the same commit twice, treat deliveries with the same `commitSha` as duplicates instead.
 -   Codacy doesn't keep a delivery log or let you resend a delivery. Log deliveries on your own endpoint if you need a record of what Codacy sent.
 
 ## See also