# Datadog

Datadog monitors your servers, databases, tools, and services, through a SaaS-based data analytics platform.

This guide shows you how to configure and test outbound webhooks for Datadog.

***

### Prerequisite

| Item                | Description                                                                                                                          |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| **Datadog API key** | [Key](https://docs.datadoghq.com/account_management/api-app-keys/#add-an-api-key-or-client-token) for accessing the Datadog REST API |

***

### Configure a webhook

Follow these steps to configure a webhook:

1. On the [**Webhooks**](https://app.apono.io/webhooks) page, click **Add Webhook**. The **Add Webhook** page appears.
2. Click **Request Webhook**.
3. Enter a unique, alphanumeric, user-friendly **Request Webhook Name** for identifying this webhook.
4. Click the **Status** toggle to **Active**.
5. From the **Method** dropdown menu, select **POST**.
6. For the webhook **URL**, enter *https\://\<DATADOG\_LOG\_COLLECTOR\_URL>/api/v2/logs*.\
   \
   Be sure to replace `<DATADOG_LOG_COLLECTOR_URL>` with your [Datadog organization location](https://docs.datadoghq.com/api/latest/logs/). For example, for the US5 region, enter: *<https://http-intake.logs.us5.datadoghq.com>*

{% hint style="warning" %}
The webhook URL **must adhere** to the following requirements:

* Uses the HTTPS protocol
* Does **not** specify any custom ports
  {% endhint %}

7. In the **Body Template** field, paste the following JSON body for the webhook payload. Replace `LOGS_TAGS` with a comma-separated list of tags you want to associate with your logs. For example `env:staging,version:5.1`.

```json
[
 {
   "ddsource": "apono",
   "ddtags": "<LOGS_TAGS>",
   "hostname": "apono",
   "message": "{ "event_type": "{{ event_type }}", "event_time": "{{ event_time }}", "id": "{{ data.id }}", "friendly_id": "{{ data.friendly_id }}", "requester_id": "{{ data.requester.id }}", "requester_name": "{{ data.requester.name }}", "requester_email": "{{ data.requester.email }}", "justification": "{{ data.justification }}", "creation_date": "{{ data.creation_date }}", "access_flow_id": "{{ data.access_flow.id }}", "access_flow_name": "{{ data.access_flow.name }}", "access_bundle_id": "{{ data.access_bundle.id }}", "access_bundle_name": "{{ data.access_bundle.id }}", "access_groups_integration_name": "{{ data.access_groups.[0].integration.name }}", "access_groups_integration_type": "{{ data.access_groups.[0].integration.type }}"}",
   "alert_type": "info",
   "service": "apono"
 }
]
```

{% hint style="success" %}
Click **View event's payload schema** to reveal the payload schema and available data fields. You can also refer to the [Webhook Payload Schema Reference](/docs/webhook-integrations/webhook-payload-references/webhook-payload-schema-reference.md) to read the descriptions of each data field.
{% endhint %}

8. For **Headers**, enter the following authorization headers. Replace the placeholder values with the API key and key ID that you [created in Datadog](/docs/webhook-integrations/request-webhook/logs-and-siems/datadog.md).

| Key                  | Value        |
| -------------------- | ------------ |
| *DD-API-KEY*         | *\<API KEY>* |
| *DD-APPLICATION-KEY* | *\<KEY ID>*  |

9. From the **Triggers** dropdown menu, select one or more of the following event triggers, which correspond to Apono access request statuses:
   * **RequestCreated**
   * **RequestApproved**
   * **RequestExpired**
   * **RequestFailed**
   * **RequestGranted**
   * **RequestRejected**
10. Under **Filters**, define one or several filter from the listed dropdown menus.

{% hint style="info" %}
Filters empower admins to control the data transmitted via webhooks, minimizing the amount of data third-party tools receive and reducing unnecessary clutter.

**Examples**:

* Send only production requests to your admins' Slack channel.
* Trigger Okta workflows for events from specific integrations or resource types.
* Open a ticket in Jira or ServiceNow for manually approved requests.
  {% endhint %}

11. (Optional) In the **Timeout in seconds** field, enter the duration in seconds to wait before marking the request as failed.
12. (Optional) Define **Response Validators** to verify that the response from the webhook meets specified criteria:
    1. Click **+ Add**. A row of settings appears.
    2. Starting with *$.data.*, enter the **Json Path** of the JSON parameter.
    3. In the **Expected Values** field, enter a value and press the Enter key on your keyboard.
    4. Repeat step **c** to add several expected values.
    5. Repeat steps **a-d** to add multiple response validators.
13. Click **Test** to generate a test event to trigger your webhook. A **Test successful** or **Test failed** response status will appear at the bottom of the page. A successful test will send mock data to the target system.

{% hint style="success" %}
For more information about the test, click **View Invocation Data**. A panel opens revealing the request, response, and other relevant details.

Should your test fail, view these tips to [troubleshoot your webhook](/docs/webhook-integrations/troubleshoot-a-webhook.md).
{% endhint %}

14. Click **Save Webhook**.

The new webhook appears in the **Webhooks** table. Active webhooks are preceded by a green dot. Inactive webhooks are preceded by a white dot.

Apono access request logs will be sent to Datadog based on the triggers you have selected.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.apono.io/docs/webhook-integrations/request-webhook/logs-and-siems/datadog.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.