Ellipse Gradient for Header

Datadog Integration Guide

Integrate Datadog with enterprise systems through REST APIs, metrics and log ingestion, selected webhook notifications, and Martini workflows.

Datadog integration options at a glance

Datadog’s primary integration mechanism is its versioned REST API, which supports metrics and log ingestion as well as management of monitors, dashboards, incidents, SLOs, hosts, tags, and other resources. Datadog also supports selected outbound webhook notifications, particularly from monitor alerts, and batch submission for compatible metrics, logs, and other endpoints. Martini can consume these APIs, submit structured HTTP payloads, expose an API endpoint for Datadog webhook requests, and orchestrate scheduled or event-driven workflows. API keys, application keys, regional Datadog sites, scoped permissions, pagination, rate limits, and endpoint-specific payload limits should be externalized and handled explicitly.

Integration pointSupported by Datadog?Common use casesHow Martini supports it
REST APIsYesSubmit metrics and logs; query observability data; manage monitors, dashboards, incidents, SLOs, hosts, tags, users, teams, and downtime schedules.Martini can consume Datadog v1 and v2 REST endpoints, apply mappings and business rules, and expose reusable APIs or workflows around Datadog operations.
Metrics and data ingestionYesSend custom metrics, logs, events, traces, and other product-specific observability payloads through HTTP ingestion endpoints.Martini workflows can transform source measurements into Datadog names, values, timestamps, tags, and structured log payloads before submission.
Webhooks / outbound callbacksLimitedSend monitor-triggered notifications to an external endpoint through Datadog’s Webhooks integration. Coverage depends on the configured monitor and notification scenario.Martini can expose a secured REST API endpoint, validate the request, route the alert, and persist identifiers for deduplication and recovery handling.
Bulk, asynchronous, and batch APIsLimitedSubmit multiple metric series or log events in one request and use batch operations available for selected Datadog resources.Martini can assemble bounded batches, split oversized payloads, and retry eligible requests without assuming batch support for every endpoint.
Database / analytics accessLimitedQuery metrics, logs, traces, and related observability data through Datadog APIs and query endpoints rather than a direct database connection.Martini can call query APIs and map returned data, but does not require or assume JDBC or direct SQL access to Datadog.
AuthenticationYesAuthenticate direct automation with API keys and application keys; use OAuth 2.0 for authorized third-party integration scenarios where applicable.Martini can externalize regional endpoints and credentials, store secrets securely, and send the required Datadog headers with scoped access.
SDKsYesUse Datadog client libraries or generated API clients for supported programming languages when implementing custom applications.Martini integrations can generally use HTTP REST workflows without requiring a Datadog SDK; custom JVM-compatible logic can be used where appropriate.
File / attachment APIsNot confirmedDatadog primarily uses structured HTTP ingestion APIs; a general-purpose file or attachment API for ordinary objects was not confirmed.Martini should use confirmed REST and ingestion endpoints rather than assume a general Datadog file interface.

How Datadog exposes data and business events

Datadog REST APIs

Datadog’s versioned REST API is the primary programmatic interface for submitting observability data and managing resources such as metrics, logs, monitors, dashboards, incidents, SLOs, hosts, and tags. API versions and regional base URLs vary by resource and organization site.

Martini implementation pattern

Martini implementation pattern: a workflow or Martini API receives a request or trigger, selects the configured Datadog regional endpoint, authenticates with the appropriate API or application key, calls the required v1 or v2 endpoint, maps the response, and applies endpoint-specific error and pagination handling.

Implementation sequence

Receive a scheduled, API, or event-based trigger
Select the Datadog regional base URL and API version
Authenticate with a scoped API key or application key
Retrieve or submit the Datadog resource
Map the response to the target model
Apply pagination, retry, and error rules

Metrics and log ingestion

Datadog provides HTTP ingestion endpoints for custom metrics, logs, events, traces, and other observability data. Metric and log submissions can support multiple items per request, subject to endpoint and payload limits.

Martini implementation pattern

Martini implementation pattern: retrieve measurements or operational messages from a source, transform them into Datadog-compatible series or log events, validate timestamps and required fields, split large payloads, and submit them using the Datadog API key.

Implementation sequence

Retrieve source measurements or operational messages
Map names, values, timestamps, and tags
Validate timestamps and required fields
Split payloads within Datadog limits
Submit the ingestion request
Record accepted and rejected items

Datadog webhook notifications

Datadog can send outbound webhook notifications through its Webhooks integration, particularly when configured monitor notifications are triggered. This is selected notification coverage rather than a universal event stream for every Datadog object.

Martini implementation pattern

Martini implementation pattern: expose a secured REST endpoint, receive the Datadog notification, validate and normalize its content, identify the monitor and alert state, apply routing rules, and invoke an incident or ticket API while preventing duplicate downstream records.

Implementation sequence

Receive the Datadog monitor notification
Authenticate or validate the inbound request
Extract monitor state, tags, message, and identifiers
Apply alert, recovery, and routing rules
Create or update the downstream incident
Return an appropriate response and store the processing result

Batch and query operations

Selected Datadog endpoints support batch submissions or query-oriented processing, including multiple metric series and log events in a request. Support, limits, and pagination behavior vary by resource and API version.

Martini implementation pattern

Martini implementation pattern: collect bounded work items, construct a resource-specific batch or query request, process paginated responses, split requests that exceed limits, and retry only transient failures with controlled backoff.

Implementation sequence

Collect a bounded set of work items
Construct the resource-specific request
Submit the batch or query
Follow endpoint-specific pagination
Split oversized requests
Retry eligible transient failures

Common Datadog integration patterns

Pattern 1: Synchronize operational metrics to Datadog

When to use this pattern

Use this pattern when measurements from a cloud platform, internal database, deployment system, or enterprise application must be standardized and submitted to Datadog for monitoring. The workflow can enforce metric naming, tag conventions, and payload limits before ingestion.

Integration direction
Source system
Martini
Datadog
Example Mapping
Datadog FieldCanonical FieldTarget Field
sourceMeasurement.namemetric.nameseries.metric
sourceMeasurement.valuemetric.valueseries.points
sourceMeasurement.timestampobservedAtseries.points.timestamp
sourceMeasurement.labelsmetric.tagsseries.tags
Martini implementation pattern

A scheduler-triggered Martini workflow retrieves measurements, maps them into Datadog series, validates timestamps and cardinality-sensitive tags, splits large submissions, and sends batches to the metrics intake API. Transient failures are retried with backoff, while rejected items are logged for correction.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • data mapping
  • batch orchestration
  • business rules
  • error handling

Pattern 2: Manage Datadog monitors from a service catalog

When to use this pattern

Use this pattern when service registration, configuration changes, or maintenance processes must create, update, search, or deactivate Datadog monitors consistently. It centralizes naming, thresholds, tags, and notification policy rules.

Integration direction
Service catalog
Martini
Datadog
Example Mapping
Datadog FieldCanonical FieldTarget Field
service.nameserviceNamemonitor.name
service.ownerownerTeammonitor.tags
alert.thresholdthresholdmonitor.query
maintenance.windowmaintenancePerioddowntime schedule
Martini implementation pattern

Martini exposes or consumes an internal API, validates the requested monitor configuration, applies organization-specific rules, and calls the Datadog monitors API with a scoped application key. The workflow stores Datadog identifiers and treats authentication, validation, rate-limit, and duplicate-name errors separately.

Martini capabilities used
  • API exposure
  • API consumption
  • data mapping
  • validation
  • business rules
  • error handling

Pattern 3: Route Datadog alerts to incident management

When to use this pattern

Use this pattern when monitor notifications should create or update incidents in ServiceNow, PagerDuty, Jira, or another operational platform. It supports alert, warning, and recovery handling while reducing duplicate incident creation.

Integration direction
Datadog
Martini
ServiceNow
Example Mapping
Datadog FieldCanonical FieldTarget Field
monitor.idsourceAlertIdcorrelation_id
alert_stateincidentStatestate
monitor.tagsserviceAndTeamassignment and service fields
messagealertDescriptiondescription
Martini implementation pattern

Datadog sends a configured webhook notification to a secured Martini API. Martini validates the request, derives a stable correlation key, classifies alert and recovery states, maps severity and ownership, and calls the incident platform. Duplicate deliveries are ignored or converted into updates, and downstream failures are retried selectively.

Martini capabilities used
  • REST API exposure
  • webhook consumption
  • data mapping
  • routing
  • deduplication
  • retry handling

Pattern 4: Normalize application logs into Datadog

When to use this pattern

Use this pattern when an application or enterprise system cannot directly emit Datadog-compatible logs, or when centralized transformation and filtering are required before ingestion. It is suitable for structured audit records and operational messages.

Integration direction
Application system
Martini
Datadog
Example Mapping
Datadog FieldCanonical FieldTarget Field
event.idsourceEventIdlog attributes.event_id
event.timestampobservedAtlog timestamp
event.levelseveritylog status
event.payloadmessageDatalog message and attributes
Martini implementation pattern

A Martini API, scheduled workflow, or source integration receives application events, validates the structure, enriches them with service and environment tags, filters restricted content, and submits bounded batches to Datadog Logs. The workflow records rejected payloads and uses source identifiers to avoid duplicate ingestion where the source supports replay.

Martini capabilities used
  • workflow triggers
  • API consumption
  • data transformation
  • validation
  • JSON handling
  • error handling

Applications commonly integrated with Datadog

Datadog commonly participates in observability, incident-management, cloud, collaboration, and enterprise operations architectures. Martini can coordinate these integrations through REST API calls, webhook-triggered workflows, data mapping, routing rules, and controlled retries.

Application Scenario Direction Martini Pattern
Amazon Web Services (AWS) Collect AWS service metrics, logs, events, and resource metadata in Datadog for infrastructure monitoring. Amazon Web Services (AWS) → Martini → Datadog Use scheduled or event-driven workflows to retrieve AWS telemetry or resource metadata, map it to Datadog metric, log, or event payloads, and submit bounded batches through the appropriate Datadog API.
Kubernetes Centralize cluster, node, pod, container, and workload health information in Datadog. Kubernetes → Martini → Datadog Normalize Kubernetes operational data or deployment events, apply naming and tag standards, and send compatible metrics or logs to Datadog while routing failures for retry or review.
Salesforce Correlate Salesforce API or application activity with operational monitoring and route Datadog alerts into Salesforce processes where required. Salesforce → Martini → Datadog Consume Salesforce APIs for selected operational data, transform it into Datadog metrics or logs, and optionally receive Datadog notifications through Martini before creating or updating Salesforce workflow records.
ServiceNow Create or update incidents and change-related records from Datadog monitor notifications. Datadog → Martini → ServiceNow Receive a Datadog webhook at a secured Martini API, deduplicate and classify the monitor state, then create or update the corresponding ServiceNow incident with mapped severity, service, and ownership fields.
PagerDuty Escalate Datadog monitor notifications to on-call responders and coordinate incident state. Datadog → Martini → PagerDuty Use Datadog webhook notifications or REST APIs to trigger a Martini workflow that maps alert state, service, and priority into PagerDuty incident operations and handles duplicate or recovery notifications.
Jira Create Jira issues from Datadog alerts and associate operational work with services or teams. Datadog → Martini → Jira Validate Datadog monitor notifications, apply routing and issue-creation rules, map tags and alert content to Jira fields, and retain identifiers for updates and deduplication.
Slack Deliver monitor, incident, and operational notifications to channels used by engineering and operations teams. Datadog → Martini → Slack Transform Datadog alert payloads into Slack messages or invoke Slack APIs from a Martini workflow, with channel routing based on service, team, severity, and monitor tags.
Microsoft Teams Deliver Datadog alert and incident notifications to operational collaboration channels. Datadog → Martini → Microsoft Teams Receive or retrieve Datadog alert information, apply team and severity routing, and send normalized notification payloads to Microsoft Teams through its available endpoint.

How to build a Datadog integration in Martini

Objective

Configure the Datadog regional site, API key, and application key requirements for the selected endpoints without embedding credentials in workflow logic.

Instructions in Martini

  • Select the organization’s Datadog regional API host
  • Use an API key for supported ingestion operations
  • Use a minimally scoped application key for management and read operations
  • Store credentials and endpoint configuration as protected environment values

Objective

Select the execution model that matches the integration: scheduled synchronization, an inbound Martini API, or a Datadog monitor webhook notification.

Instructions in Martini

  • Use a scheduler for polling and metric synchronization
  • Expose a secured Martini REST API for inbound Datadog notifications
  • Use workflow triggers for source-system events where available
  • Define the expected replay and duplicate-delivery behavior

Objective

Obtain Datadog resources or source-system data through the appropriate REST, ingestion, query, or webhook mechanism.

Instructions in Martini

  • Call the selected Datadog v1 or v2 endpoint
  • Receive and validate configured webhook notifications
  • Follow endpoint-specific pagination
  • Use bounded requests for metrics and logs

Objective

Coordinate API calls, transformations, routing, persistence, and downstream operations in a maintainable Martini workflow.

Instructions in Martini

  • Separate retrieval, transformation, business rules, and delivery stages
  • Store source and Datadog identifiers needed for correlation
  • Route alert, recovery, and error paths explicitly
  • Reuse common API and validation logic where appropriate

Objective

Convert source payloads into Datadog metrics, logs, monitor definitions, incident data, or downstream records while preserving meaningful identifiers and timestamps.

Instructions in Martini

  • Map fields to the selected Datadog resource model
  • Standardize metric names, tags, and severity values
  • Preserve timestamps and timezone information
  • Validate required fields and remove or protect restricted content

Objective

Enforce organization-specific controls for permissions, routing, thresholds, deduplication, monitor state, and payload sizing.

Instructions in Martini

  • Distinguish alert, warning, and recovery states
  • Apply service and team routing from monitor tags
  • Limit application-key operations to approved use cases
  • Split payloads that exceed endpoint limits

Common Datadog data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
MetricsSubmit and query time-series measurements with names, values, timestamps, and tags.AWS, Kubernetes, internal databases, deployment platforms, dashboardsMartini maps source measurements into Datadog metric series, standardizes names and tags, batches compatible submissions, and handles timestamp and payload validation.
LogsIngest, search, index, archive, and query application or operational log events.Application platforms, cloud services, SIEM and incident workflowsMartini normalizes structured log fields, preserves source timestamps and timezone information, submits bounded payloads, and routes rejected messages for review.
MonitorsDefine alerting and detection logic over metrics, logs, traces, synthetics, or other Datadog data.ServiceNow, PagerDuty, Jira, Slack, Microsoft TeamsMartini can create, update, search, or deactivate monitors through permitted APIs, applying naming, tagging, threshold, and maintenance rules.
DashboardsPresent configurable visualizations for metrics, logs, traces, SLOs, and related data.Configuration repositories, service catalogs, operational portalsMartini can retrieve or update dashboard resources where the selected endpoint and application-key permissions support the operation.
IncidentsTrack incident status, severity, responders, timelines, and related operational information.ServiceNow, PagerDuty, Jira, collaboration platformsMartini maps Datadog incident or alert information to downstream incident models, stores cross-system identifiers, and distinguishes new, ongoing, and recovered conditions.
Service Level Objectives (SLOs)Define reliability objectives based on monitored service-level indicators.Service catalogs, reporting stores, operational dashboardsMartini can retrieve SLO data through Datadog APIs, transform it for reporting or governance workflows, and apply validation and retry policies.

Authentication and security considerations

Credentials and permissions

Datadog commonly uses an API key for organization identification and supported data ingestion, and an application key for management and read operations. Application keys should be restricted to the minimum permissions required by each Martini workflow.

Regional endpoints

Datadog organizations use regional sites such as US1, US3, US5, EU, AP1, or AP2. Store the regional API host as configuration rather than assuming one global endpoint.

Webhook protection

Receive Datadog webhook notifications through a secured Martini API and apply authentication or request-validation controls appropriate to the configured integration. Do not expose an unauthenticated endpoint without compensating controls.

OAuth and secrets

Datadog documents OAuth 2.0 for authorized third-party integrations, while direct automation commonly uses API and application keys. Keep all credentials in protected Martini configuration or secrets management.

Operational considerations for Datadog integrations

Rate limits and retries

Datadog rate limits vary by endpoint and account plan. Detect HTTP 429 responses, honor available retry guidance, use bounded backoff, and avoid unnecessary polling.

Pagination and batching

List and search APIs may require pagination, while metric and log ingestion supports batching for selected workloads. Follow endpoint-specific pagination fields and split payloads that exceed documented limits.

Idempotency and monitor state

Webhook deliveries and retried workflows can produce duplicates. Use stable identifiers and distinguish alert, warning, and recovery transitions so downstream systems do not open multiple incidents for one condition.

Schema and cardinality

Datadog API versions and resource models can change. Validate mappings when moving between v1 and v2, and standardize metric names and tags to avoid uncontrolled high-cardinality data.

Testing and observability

Test authentication, validation, pagination, rate-limit, oversized-payload, and recovery paths. Monitor Martini workflow logs and preserve request correlation information without exposing credentials or sensitive payloads.

Why use Martini instead of scripts or point-to-point integrations?

Orchestration instead of isolated scripts

Martini coordinates Datadog API calls, inbound webhook handling, transformations, routing, and downstream writes in a maintainable workflow rather than scattering logic across scripts.

Reusable integration assets

Teams can expose controlled Martini APIs, reuse authentication and validation logic, and create consistent workflows for metrics, logs, monitor management, and incident routing.

Reliable data movement

Martini supports mapping, business rules, pagination, batching, bounded retries, error paths, and environment-specific configuration so Datadog integrations can be operated consistently as requirements evolve.

Flexible implementation

When standard HTTP workflows are insufficient, Martini can be extended with custom JVM-compatible logic while retaining the surrounding workflow, security, and operational structure.

Frequently asked questions

How can Datadog be integrated with enterprise systems?

Datadog can be integrated through its versioned REST APIs, HTTP metrics and log ingestion endpoints, selected batch operations, and outbound webhook notifications configured for supported monitor scenarios. Enterprise workflows can retrieve or submit observability data, manage monitors and dashboards, and route alerts to incident and collaboration systems.

Can Martini integrate with Datadog?

Yes. Martini can consume Datadog REST APIs, submit metrics and logs to Datadog ingestion endpoints, query supported observability resources, and receive selected Datadog webhook notifications through a Martini REST API. A Datadog-specific native Martini connector was not confirmed in the supplied documentation.

Do I need a connector to integrate Datadog with Martini?

No. A dedicated Datadog connector is not required. Martini can use Datadog’s confirmed REST APIs, HTTP ingestion endpoints, API and application key authentication, and configured webhook notifications through workflows and APIs.

Is there any extra Lonti cost to integrate Datadog with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Datadog. The integration is subject to the provisioned capacity of the Martini environment. Separate Datadog, cloud infrastructure, or other third-party costs may apply depending on subscription, usage, and deployment model.

Which Datadog integration methods should an enterprise use?

REST APIs are Datadog’s primary programmatic mechanism for resource management, querying, and data submission. Use metrics or logs ingestion endpoints for observability payloads, selected batch operations for compatible workloads, and webhooks for monitor-triggered notifications where outbound alert delivery is needed.

Can Datadog send alerts or events to Martini?

Datadog can send outbound webhook notifications from configured monitor notifications and selected notification integrations. This should not be treated as a universal event stream for every Datadog resource. Martini can receive, validate, route, and deduplicate those notifications.

How does Martini synchronize Datadog data?

Martini can run scheduled workflows that retrieve paginated metrics, logs, incidents, SLOs, hosts, or other resources, then map them to a target system. It can also submit source-system metrics and logs to Datadog. Checkpoints, stable identifiers, pagination, rate-limit handling, and bounded retries should be designed per endpoint.

How are errors, retries, and duplicate Datadog notifications handled?

Martini can classify authentication, validation, rate-limit, transient server, and permanent resource errors, retry eligible transient failures with controlled backoff, and route non-retryable failures for review. Stable monitor, incident, or source-event identifiers support idempotent downstream processing, although Datadog operations should not be assumed idempotent unless documented.

Related Martini documentation

Webhooks

Workflows

Security

Operations

Integrate Datadog with Martini

Use Martini to build maintainable Datadog integrations for observability data ingestion, API-led resource management, monitor notifications, and incident workflows.

EXPLORE MARTINI
BOOK A DEMO