How to integrate Unify with Datadog
To integrate Unify with Datadog, send a small operational log from a Play to the HTTP Logs intake endpoint for your Datadog site. Authenticate with DD-API-KEY and include a useful message and service name. The v2 intake acknowledgement confirms acceptance for processing; inspect the log separately to verify visibility.[1][3]
- Connection
- Via webhook
- Observability
- Tool
- Datadog
- Datadog HTTP Logs intake
- Data flow
- Unify → Datadog
- JSON payload
At a glance
- Define exactly what the checkpoint proves
- Send only useful operational context
- Inspect the log in the right site and time window
When this workflow makes sense
Start with the decision your team needs to make, then choose the connection that supports it.
An operational log is useful when it answers a specific question: did this record reach the configured handoff point? Keep that meaning narrow. The component that performs a later action should report its own completion or failure, so an intake log does not become a misleading success signal.
A good fit when
Teams using Datadog to investigate application handoffs and able to maintain log filters and ownership.
Reconsider the plan when
If the goal is simply to notify a rep about a prospect, a team notification may be more useful than a log that no one monitors.
Design the handoff
Use this framework to agree on the input, the next action, and who owns the result.
Suggested workflow design, based on the documented capabilities below.
| Stage | Decision to make |
|---|---|
| Meaning | Define exactly what the checkpoint proves |
| Fields | Send only useful operational context |
| Visibility | Inspect the log in the right site and time window |
| Alerting | Treat any monitor as a separate configured and tested outcome |
Explore the scenarios
Choose the situation that fits your team and work through the proposed plan.
Open a scenario to explore its plan. Checklists track your selections in this page only.
Trace a selected handoff checkpoint
Operators need to know whether a Play reached a specific step.
Keep the message tied to that observable step.
- Name the checkpoint and service
- Send the fictional test log
- Find it with the intended filters
Separate intake from downstream failure
A later application operation can fail after the Play sends its log.
Use different evidence for receipt and completion.
- Define both checkpoints
- Record the downstream result in its owning component
- Compare their meaning during a controlled failure
Illustrative workflow, not a preconfigured automation. Complete these checks in your own account.
Define success before launch
Inspect the data and the intended outcome separately. Connection status is only the first check.
Expected, not tested
The fictional checkpoint is visible in the intended Datadog log view with the expected service and tags.
Check the actual searchable log and any separately configured monitor. The v2 API returns acceptance for processing, not a promise that a monitor fired.
Documentation-based reference. This workflow has not been tested end to end. Use a record or event you control before enabling live activity.
Questions answered
Common decisions when connecting Unify and Datadog.
What can Unify send to Datadog?
The Webhook action can send a custom HTTP payload. This example uses Datadog’s documented log schema to report a Play checkpoint.[1]
Which Datadog endpoint should I use?
Use the v2 Logs intake hostname for your organization’s site. The US1 example is not the correct hostname for every region.[3]
Does a 202 response mean the monitor fired?
No. It confirms acceptance for processing. Inspect the log and any monitor outcome separately.[3]
Should I log the entire prospect record?
This design uses a minimal operational message. Choose only the fields needed to understand the checkpoint instead of copying the full record by default.[1]
Does this monitor every Unify failure automatically?
No. It reports only a Play action that reaches this configured webhook. Broader coverage requires its own instrumentation and monitoring design.[1]
Limits & decisions
Check these boundaries before designing a live workflow around the connection.
- This is log intake, not automatic monitoring of all Unify activity
- A log checkpoint does not prove another downstream action completed
- Site, processing, indexing, and monitor settings affect what operators see
- No live Datadog log or alert was created
What the connection supports
Understand the connection, the data involved, and the behavior that matters for a Unify + Datadog workflow.
POST / JSON
| Decision | What to know |
|---|---|
| Transport | POST JSON to the site-specific HTTP Logs intake[3] |
| Credential | DD-API-KEY authenticates log intake[3] |
| Log body | message is used as the log body[3] |
| Organization | service and tags support operational context[3] |
| Acknowledgement | The v2 request is accepted for processing with HTTP 202[3] |
Technical setup reference
References and requirements for the Datadog connection.
Connection requirements and setup checklist
Before connecting
- A Unify Play with a Webhook action
- A Datadog organization, its site, and an API key for log intake
- A service label and a minimal log message with a defined operational meaning
- Someone who owns log visibility and any separately configured monitor
Define the checkpoint
Choose what the log can truthfully establish, such as the Play reaching this webhook action. Do not label it as proof that a different destination operation succeeded.[1]
Add alerting deliberately
If a monitor is needed, configure and test it as a separate Datadog operation. One received log does not establish complete coverage of every Play or delivery failure.[5]
Request configuration
- Method
POST- URL pattern
https://http-intake.logs.datadoghq.com/api/v2/logs- Headers
Content-Type: application/jsonDD-API-KEY: YOUR_DATADOG_API_KEY- Authentication
- Use API Key (Header) in Unify with DD-API-KEY and the Datadog API key. Choose the intake hostname for your Datadog site; the URL shown is the US1 example.
Choose JSON as the body format. Unify sets Content-Type automatically. The receiver must respond within Unify’s 8-second timeout; request responses are not passed to later Play steps.[2]
Replace URL placeholders with the actual receiver URL from your account or deployed application. These example URLs are not working endpoints.
Example handoff payload
Start with a fictional prospect. Validate the resolved values before using a real record.
Inspect the sample payload and field mapping
{
"message": "Unify Play reached the review handoff checkpoint",
"service": "unify-prospect-handoff",
"ddsource": "unify",
"ddtags": "env:test,workflow:prospect-review"
}Fictional data. Replace sample values before using a real Play.
Fictional operational checkpoint with no personal prospect fields. Labels are examples, not built-in Unify observability events. Use the field mapping to distinguish record data from fixed settings. Select available fields in your Play and inspect Expand preview; do not replace configuration values with prospect data.[2][3]
| Payload field | Value to send |
|---|---|
message | Use a message that describes this observable checkpoint only |
service | Choose a stable service label |
ddsource | Choose the source label for this feed |
ddtags | Use labels appropriate to the actual environment |
The example logs an operational checkpoint rather than a prospect profile. Its service and tags are fixed labels you choose. If adding dynamic values, use only documented Play fields and validate the rendered JSON; never include credentials in the log message.
Troubleshooting
Start with the stage where the expected data or action stops appearing.
Authentication fails
Compare the site-specific hostname and the organization that owns the API key. Confirm that DD-API-KEY is set on the request.[3][4]
The request is accepted but I cannot find the log
Inspect the selected site, time range, service filter, and log processing or indexing configuration. Acceptance is the first checkpoint.[3][5]
The log says a task finished even when it failed
Change the message to the event this Play action can actually observe. Record a downstream operation’s final state at the component that owns it.[1]
Sources & review
Official documentation reviewed on September 15, 2026.
Technical claims link to primary documentation from Unify and the destination tool. Scenarios, field choices, and recovery plans are editorial implementation examples. Documentation review is separate from execution testing.
Documentation reviewed; end-to-end execution not tested. No named technical reviewer has signed off on these articles yet.
Content updated: . Report a correction to Unify with the tool name, source URL, and behavior you observed.
Keep exploring
