Webhook payload format examples

The following sample webhook payloads show the parts of a payload and descriptions of each part.

For details on triggering webhooks, see Trigger webhooks for other applications.

In this topic:

Sample payload for an update event

The payload for an update event consists of the following parts: 

Part Description
Header information

Sent with every Trigger webhook rule, and consists of:

  • server_url
  • event_type
  • username
  • sharedspace_id
  • workspace_id
Basic information

Fields that are sent with every Trigger webhook rule. These fields include: 

  • id: ID of the entity.
  • type: Type of entity.

  • audit_id: Activity log ID of the triggering event, if the event was recorded in the activity log. For details, see View the activity log.

    Note: If an event exceeds the maximum length allowed for an activity log entry, the event is split and logged as multiple entries in the activity log. The webhook payload contains the entire record of the event, and the payload's audit_id value matches the ID of the first activity log entry of the event. The other event entries can be associated with the event using the property aggregated_event_id, which has the same value across all of the event's entries.
Additional information Additional fields that you can add to the request payload, using Fields when setting up the Trigger webhook rule.
Changes

If the event_type is update, the changes field is included in the request payload.

The changes field includes the set of changes, including the values before and after the update.

Back to top

Usage of payload field types

The following sample payload highlights the usage of various field types.

Field type Sample snippets
Primitive

Basic system fields, such as id, type, last_modified. 

"changes": {
  "last_modified": {
    "oldValue": "2017-12-26T15:51:22Z",
    "newValue": "2017-12-26T15:49:22Z"
  }
}
User

User information. 

"detected_by": {
  "id": 1991,
  "type": "workspace_user",
  "email": "MyEmail@MyCompany.com"
}

"changes": {
  "detected_by": {
    "oldValue": null,
    "newValue": {
      "id": 1002,
      "type": "workspace_user",
      "email": "YourEmail@YourCompany.com"
    }
  }
}
List node

Object of type and ID, such as phases.

"phase": {
  "type": "phase",
  "id": "phase.defect.new"
}

"changes": {
  "phase": {
    "oldValue": {
      "type": "phase",
      "id": "phase.test_manual.new"
    },
    "newValue": {
      "type": "phase",
      "id": "phase.test_manual.planned"
    }
  }
}
Multi-list nodes

Total count in addition to the array of list nodes, such as the list of test types.

"test_type": {
  "total_count": 2,
  "data": [
    {
      "type": "list_node",
      "id": "list_node.test_type.performance"
    },
    {
      "type": "list_node",
      "id": "list_node.test_type.regression"
    }
  ]
}

"changes": {
  "test_type": {
    "oldValue": [
      {
        "type": "list_node",
        "id": "list_node.test_type.performance"
      },
      {
        "type": "list_node",
        "id": "list_node.test_type.regression"
      }
    ],
    "newValue": [
      {
        "type": "list_node",
        "id": "list_node.test_type.performance"
      }
    ]
  }
}
Reference

Object of type and id, such as release. 

"release": {
  "type": "release",
  "id": "2002"
}
Multi-reference

Total count in addition to the array of reference entities, such as application modules (previously known as product areas). 

"application_modules": {
  "total_count": 2,
  "data": [
    {
      "type": "application_module",
      "id": "2002"
    },
    {
      "type": "application_module",
      "id": "2001"
    }
  ]
}

"changes": {
 "application_modules": {
    "oldValue": [
      {
        "id": 1001,
        "type": "application_module"
      }
    ],
    "newValue": [
      {
        "id": 1002
        "type": "application_module",
      }
    ]
  }
}

Back to top