{"_id":"5cf569e2e34a9e0326c6ffe7","project":"564e5930c3553e0d003e53d0","version":{"_id":"564e5a9b1560880d008d30dc","project":"564e5930c3553e0d003e53d0","__v":26,"createdAt":"2015-11-19T23:26:19.166Z","releaseDate":"2015-11-19T23:26:19.166Z","categories":["564e5a9b1560880d008d30dd","566318e1f5ca460d00f41896","56631d08cd54d50d005015fa","56631d2a81ad7417006a202c","5668ba19fbd7680d009375f4","5668cb8b10bda80d00797ed9","5668cb9d10bda80d00797eda","56830d8a3f94e00d004e2a7a","56830d9072bb720d0091f594","56830d94cb4d190d0027698e","56830dc44aecbd0d00a464c5","569e90f3c9b43e0d00c4bab1","56a96d338791090d00113bab","56b12d8336d2580d00247877","56c36bf0a869d017002ea55b","56c36bf93d30210d00ea84bb","56c77749b935671700ff0304","56c7ab9e5652c217008e091a","56cb8bdad5c6241d00ef5e61","58aefce02470660f00b54539","58aefd0bebd7370f0078b954","59ca65ca4337830026edf24f","5c33cd9eb47ba20051ac8d64","5c33df728bec1d0063431c34","5c4783ef523219027055513a","5c4f35033400f3010203a999"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"Foundation","version_clean":"2.0.0","version":"2"},"category":{"_id":"5c4783ef523219027055513a","project":"564e5930c3553e0d003e53d0","version":"564e5a9b1560880d008d30dc","__v":0,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2019-01-22T20:58:23.001Z","from_sync":false,"order":1,"slug":"tools-libraries","title":"Libraries, Tools, and Examples"},"user":"5bbfe5dfe752030003c5cb52","__v":0,"parentDoc":null,"updates":[],"next":{"pages":[],"description":""},"createdAt":"2019-06-03T18:41:38.429Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":7,"body":"The original details of any event sent from your monitoring tools to PagerDuty, whether an email sent through an email integration or JSON-encoded data through an API-based integration, can be retrieved through the REST API. This process requires the use of our Log Entries API with channels included, which will expose the original data received through the integration.\n\n##Introduction\n\nAs noted on our [Log Entries API](https://v2.developer.pagerduty.com/v2/page/api-reference#!/Log_Entries/get_log_entries) documentation:\n\n> PagerDuty keeps a log of all the events that happen to an incident. These are exposed as log entries. Log entries give you more insight into how your team or organization is handling your incidents.\n\nLog entry data includes details about the event(s) that affected the incident throughout its lifecycle, such as:\n\n* the data contained in events sent by the integration\n* what users were notified and when\n* how they were notified\n* what user(s) acknowledged or resolved the incident\n* any automatic actions that occurred to the incident\n* other manual user actions, such as a reassignment or a note\n\n## How to obtain the data\n\nTo obtain the event data sent through the integration, we'll be retrieving a specific type of log entry called the trigger log entry. For this, you will need the ID (a string of alphanumeric characters that starts with `P`) or the number of the incident that the event triggered. \n\nIn both cases, we'll be making requests to the log entries API. We will need to append the `channels` value to the array-type URL parameter `include[]` when obtaining log entries. In other words, the query part of the URL (after `?`) will contain `include[]=channels`, to enable including this feature in the response.\n\nThe two ways of getting the trigger log entry are as follows:\n\n1. **With just the incident number (or ID):** \n    1. Obtain the first trigger log entry (which initially triggered the incident) by [retrieving the incident via `GET /incidents/{id}`](https://v2.developer.pagerduty.com/v2/page/api-reference#!/Incidents/get_incidents_id), where `{id}` could be the ID or the incident number.\n    2.  From the `first_trigger_log_entry` property in the response, make a second `GET` request to the URL in its `self` property, which should lead to [the endpoint to retrieve an individual log entry, `/log_entries/{id}`](https://v2.developer.pagerduty.com/v2/page/api-reference#!/Log_Entries/get_log_entries_id)\n2. **With the incident ID:** You can obtain all trigger log entries in one or more API calls by:\n    1. Use the [incident log entries endpoint at `/incidents/{id}/log_entries`](https://v2.developer.pagerduty.com/v2/page/api-reference#!/Incidents/get_incidents_id_log_entries), where `{id}` is the incident ID.\n    2. Use the first log entry in the array (`log_entries` property in the response), which should contain a `log_entry` type object whose `type` value is `trigger_log_entry`.\n\nNote that using the second method, it is possible to obtain subsequent alert data sent by the monitoring tool (after the incident was initially triggered) by iterating through all log entries and selecting the entries whose `type` value is `trigger_log_entry`.\n\n##The channel property of log entries\n\nEach log entry object returned will then contain a `channel`, if `channels` was in the `include` parameter. This property will itself contain an object with the triggering event data. Note the following about this property:\n\n* The structure of the object in the channel property will vary, but it will always contain a property named `type`.\n* For trigger log entries, the type property will be `api`, `email` or `web_trigger`.\n* The overall structure of the `channel` object depends on the `type` value.\n\n[block:callout]\n{\n  \"type\": \"info\",\n  \"body\": \"The description of the structure of the `log_entry.channel` produced here only reflects what it was observed to be as of this writing. A full specification of the `log_entry.channel` property's schema has not yet been published in our API Reference because it may be subject to change until a permanent structure is decided upon.\",\n  \"title\": \"Disclaimer\"\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"0-1\": \"It will contain the properties of the event that was received through the integration.\\n**Note**: This type appears for both Event and REST API.\",\n    \"1-1\": \"It will contain aptly-named properties `subject`, `body`, `from` and `to`, in addition to a property `summary` containing the short event description extracted from the email per management rules (if nothing, this will be the subject header of the email).\",\n    \"2-1\": \"Will contain `subject` (short description / incident title), `details` (long description entered in the \\\"New Incident\\\" form) and `summary` (usually same as the title)\",\n    \"3-1\": \"It will contain the ` summary` which is identical to the `subject` and `details`.\",\n    \"0-0\": \"`api`\",\n    \"1-0\": \"`email`\",\n    \"2-0\": \"`website`\",\n    \"3-0\": \"`mobile`\",\n    \"h-0\": \"channel type\",\n    \"h-1\": \"description\"\n  },\n  \"cols\": 2,\n  \"rows\": 4\n}\n[/block]","excerpt":"","slug":"retrieve-incident-details-using-the-rest-api","type":"basic","title":"Retrieve Incident Details Using the REST API"}

Retrieve Incident Details Using the REST API


The original details of any event sent from your monitoring tools to PagerDuty, whether an email sent through an email integration or JSON-encoded data through an API-based integration, can be retrieved through the REST API. This process requires the use of our Log Entries API with channels included, which will expose the original data received through the integration. ##Introduction As noted on our [Log Entries API](https://v2.developer.pagerduty.com/v2/page/api-reference#!/Log_Entries/get_log_entries) documentation: > PagerDuty keeps a log of all the events that happen to an incident. These are exposed as log entries. Log entries give you more insight into how your team or organization is handling your incidents. Log entry data includes details about the event(s) that affected the incident throughout its lifecycle, such as: * the data contained in events sent by the integration * what users were notified and when * how they were notified * what user(s) acknowledged or resolved the incident * any automatic actions that occurred to the incident * other manual user actions, such as a reassignment or a note ## How to obtain the data To obtain the event data sent through the integration, we'll be retrieving a specific type of log entry called the trigger log entry. For this, you will need the ID (a string of alphanumeric characters that starts with `P`) or the number of the incident that the event triggered. In both cases, we'll be making requests to the log entries API. We will need to append the `channels` value to the array-type URL parameter `include[]` when obtaining log entries. In other words, the query part of the URL (after `?`) will contain `include[]=channels`, to enable including this feature in the response. The two ways of getting the trigger log entry are as follows: 1. **With just the incident number (or ID):** 1. Obtain the first trigger log entry (which initially triggered the incident) by [retrieving the incident via `GET /incidents/{id}`](https://v2.developer.pagerduty.com/v2/page/api-reference#!/Incidents/get_incidents_id), where `{id}` could be the ID or the incident number. 2. From the `first_trigger_log_entry` property in the response, make a second `GET` request to the URL in its `self` property, which should lead to [the endpoint to retrieve an individual log entry, `/log_entries/{id}`](https://v2.developer.pagerduty.com/v2/page/api-reference#!/Log_Entries/get_log_entries_id) 2. **With the incident ID:** You can obtain all trigger log entries in one or more API calls by: 1. Use the [incident log entries endpoint at `/incidents/{id}/log_entries`](https://v2.developer.pagerduty.com/v2/page/api-reference#!/Incidents/get_incidents_id_log_entries), where `{id}` is the incident ID. 2. Use the first log entry in the array (`log_entries` property in the response), which should contain a `log_entry` type object whose `type` value is `trigger_log_entry`. Note that using the second method, it is possible to obtain subsequent alert data sent by the monitoring tool (after the incident was initially triggered) by iterating through all log entries and selecting the entries whose `type` value is `trigger_log_entry`. ##The channel property of log entries Each log entry object returned will then contain a `channel`, if `channels` was in the `include` parameter. This property will itself contain an object with the triggering event data. Note the following about this property: * The structure of the object in the channel property will vary, but it will always contain a property named `type`. * For trigger log entries, the type property will be `api`, `email` or `web_trigger`. * The overall structure of the `channel` object depends on the `type` value. [block:callout] { "type": "info", "body": "The description of the structure of the `log_entry.channel` produced here only reflects what it was observed to be as of this writing. A full specification of the `log_entry.channel` property's schema has not yet been published in our API Reference because it may be subject to change until a permanent structure is decided upon.", "title": "Disclaimer" } [/block] [block:parameters] { "data": { "0-1": "It will contain the properties of the event that was received through the integration.\n**Note**: This type appears for both Event and REST API.", "1-1": "It will contain aptly-named properties `subject`, `body`, `from` and `to`, in addition to a property `summary` containing the short event description extracted from the email per management rules (if nothing, this will be the subject header of the email).", "2-1": "Will contain `subject` (short description / incident title), `details` (long description entered in the \"New Incident\" form) and `summary` (usually same as the title)", "3-1": "It will contain the ` summary` which is identical to the `subject` and `details`.", "0-0": "`api`", "1-0": "`email`", "2-0": "`website`", "3-0": "`mobile`", "h-0": "channel type", "h-1": "description" }, "cols": 2, "rows": 4 } [/block]