Blame
|
1 | # Webhooks |
||||||
| 2 | ||||||||
|
3 | Webhooks allow an external service to deliver a signed event to AeThex. |
||||||
|
4 | |||||||
|
5 | | Field | Value | |
||||||
| 6 | |---|---| |
|||||||
| 7 | | Documentation status | Active | |
|||||||
| 8 | | Current uses | Signed deployment events and Discord interactions | |
|||||||
| 9 | | Last source review | 2026-06-26 | |
|||||||
|
10 | |||||||
|
11 | ## Deployment webhooks |
||||||
|
12 | |||||||
|
13 | The AeThex API currently exposes signed deployment webhook handlers for selected repositories. |
||||||
|
14 | |||||||
|
15 | The receiver: |
||||||
| 16 | ||||||||
| 17 | 1. Reads the signature from the configured Gitea or GitHub signature header. |
|||||||
| 18 | 2. Computes an HMAC SHA-256 value using the shared webhook secret. |
|||||||
| 19 | 3. Rejects an invalid signature with `401`. |
|||||||
| 20 | 4. Ignores branches other than `main`. |
|||||||
| 21 | 5. Acknowledges the accepted event before starting the deployment script. |
|||||||
| 22 | ||||||||
| 23 | Deployment webhook URLs and secrets are operational credentials and are not published here. |
|||||||
| 24 | ||||||||
| 25 | ## Discord interactions |
|||||||
| 26 | ||||||||
| 27 | Discord sends interactions to `/discord/interactions`. |
|||||||
| 28 | ||||||||
| 29 | The receiver verifies: |
|||||||
| 30 | ||||||||
| 31 | - `x-signature-ed25519`. |
|||||||
| 32 | - `x-signature-timestamp`. |
|||||||
| 33 | - The raw request body. |
|||||||
| 34 | ||||||||
| 35 | Invalid requests return `401`. Valid Discord ping requests receive the required handshake response. |
|||||||
|
36 | |||||||
| 37 | ## Receiver checklist |
|||||||
| 38 | ||||||||
|
39 | - Read and preserve the raw body when the provider signs raw bytes. |
||||||
| 40 | - Verify the signature before processing the payload. |
|||||||
| 41 | - Compare signatures safely. |
|||||||
| 42 | - Reject stale timestamps when the provider supports replay protection. |
|||||||
| 43 | - Return quickly and move long work to a background process. |
|||||||
| 44 | - Make repeated deliveries idempotent. |
|||||||
| 45 | - Never log active webhook secrets. |
|||||||
| 46 | - Rotate secrets after suspected exposure. |
|||||||
| 47 | ||||||||
| 48 | ## Delivery behavior |
|||||||
| 49 | ||||||||
| 50 | Clients should expect: |
|||||||
| 51 | ||||||||
| 52 | - Duplicate delivery. |
|||||||
| 53 | - Out-of-order delivery. |
|||||||
| 54 | - Network timeout after the receiver accepted the event. |
|||||||
| 55 | - Provider retries. |
|||||||
| 56 | ||||||||
| 57 | Use a provider event ID or another idempotency key when mutating state. |
|||||||
| 58 | ||||||||
| 59 | ## Related documentation |
|||||||
| 60 | ||||||||
| 61 | - [[Discord Integration]] |
|||||||
| 62 | - [[Authentication]] |
|||||||
| 63 | - [[Security]] |
|||||||
| 64 | - [[KAEL Safety]] |
|||||||