Skip to content

Payload Structure

Every webhook request (using the Raw format) contains a JSON body with two top-level fields:

  • event — the event type that triggered the request.
  • data — the event payload.

Here is an example of a job_finished event:

{
  "event": "job_finished",
  "data": {
    "id": "16555c02-a320-4bec-a14a-52754d783970",
    "appBuildId": "647d1fe4-9cb7-4f25-afaf-7a0c13a1bb8c",
    "appDeploymentId": null,
    "appId": "70922e93-0944-48cc-a560-61135ab291ad",
    "finishedAt": 1771143284003,
    "inProgressAt": 1771143275311,
    "inProgressTimeInSeconds": 8,
    "organizationId": "a7249949-a705-4952-a293-a06df84950dc",
    "pendingAt": 1771143256381,
    "queuedAt": null,
    "stack": "macos-tahoe",
    "status": "canceled",
    "totalTimeInSeconds": 27,
    "createdAt": 1771143256161,
    "createdBy": "f624e455-b19c-4f17-8282-e4a7a02597f3"
  }
}

Reading the payload

The exact fields inside data depend on the event type, but a few conventions hold across all of them:

  • IDs are UUIDs. Fields like id, appId, and organizationId identify the resource and let you correlate the event with what you already know.
  • Timestamps are Unix epoch milliseconds. Lifecycle fields such as queuedAt, pendingAt, inProgressAt, and finishedAt mark each stage; a null means that stage didn't occur (here, the job was canceled before it queued).
  • status carries the outcome of a finished job — for example succeeded, failed, or canceled — which is usually the field your integration branches on.
  • Related resources are linked by ID. A job points back to its build or deployment via appBuildId / appDeploymentId; the unused one is null.

Always switch on the top-level event first, then read the data fields that apply to that event.

To make sure a request really came from Capawesome Cloud, verify its signature.