.png)
Honeycomb Integration Guide
Connect Honeycomb observability data with enterprise systems through REST APIs, OpenTelemetry ingestion, batch events, queries, and selected trigger notifications.
Honeycomb integration options at a glance
Honeycomb supports REST APIs for event ingestion, batch event submission, queries, query results, environments, datasets, triggers, SLOs, and administration. It also supports OpenTelemetry ingestion through supported OTLP HTTP or gRPC configurations for telemetry workflows. Selected alerting and trigger use cases can send webhook-style notifications, while query and administrative endpoints may require pagination or asynchronous polling. Honeycomb API authentication commonly uses the X-Honeycomb-Team header with environment- or team-scoped permissions. Martini can consume these APIs, receive selected notifications, transform upstream data into Honeycomb events, schedule query workflows, and expose controlled REST endpoints for downstream systems.
| Integration point | Supported by Honeycomb? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Send individual events, run queries, retrieve query results, and manage environments, datasets, triggers, SLOs, markers, and other observability resources. | Martini can consume Honeycomb REST endpoints, map request and response data, expose controlled REST façades, and orchestrate multi-step API workflows. |
| OpenTelemetry ingestion | Yes | Ingest traces, metrics, and logs through supported OTLP HTTP or gRPC transport patterns, depending on telemetry type and Honeycomb configuration. | Martini can route or orchestrate telemetry-related workflows where the payload and transport are supported, while preserving the distinction between OTLP ingestion and Honeycomb REST management APIs. |
| Bulk / async / batch APIs | Yes | Submit multiple Honeycomb events in a request when processing records from databases, files, queues, or upstream applications. | Martini can group mapped events into batches, control concurrency, interpret partial failures, and retry only eligible items. |
| Webhooks / outbound callbacks | Limited | Receive selected Honeycomb trigger or alert notifications through configured webhook-style destinations; this is not a universal event stream. | Martini can expose a REST endpoint or webhook workflow, validate notifications, deduplicate them, enrich payloads, and forward them to operational systems. |
| Query and query-result APIs | Yes | Submit analytical queries, retrieve results, generate reports, evaluate thresholds, and synchronize selected observability data with other systems. | Martini can schedule query workflows, poll asynchronous results where required, apply business rules, and transform results into reports or downstream API requests. |
| File / attachment APIs | No | No general-purpose Honeycomb file or attachment API was confirmed. Honeycomb is primarily an event and observability-data platform. | Martini can read files from other systems and transform their contents into Honeycomb events when the resulting payload meets ingestion requirements. |
| Database / analytics access | Limited | Honeycomb exposes analytical query capabilities through APIs, but no general relational database or JDBC access was confirmed. | Martini should use Honeycomb query APIs rather than database drivers and can combine query responses with SQL or other enterprise data sources. |
| Authentication | Yes | Authenticate API requests with API keys, commonly through the X-Honeycomb-Team header, with scope and permissions varying by key type and endpoint. | Martini can store keys in protected secrets or environment configuration and inject them into workflows without hard-coding credentials. |
How Honeycomb exposes data and business events
Honeycomb REST APIs
Honeycomb provides HTTP APIs for event ingestion, queries, query results, environments, datasets, triggers, SLOs, markers, and administration. The exact endpoint permissions depend on the API key and Honeycomb resource involved.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates with a protected API key, calls the required Honeycomb endpoint, validates the response, maps data to a canonical model, and routes the result to another API or workflow branch.
Implementation sequence
OpenTelemetry ingestion
Honeycomb supports OpenTelemetry ingestion through supported OTLP HTTP and gRPC transport patterns, depending on the telemetry type and ingestion configuration. OTLP is distinct from Honeycomb’s REST APIs for management and event operations.
Martini implementation pattern
Martini implementation pattern: use Martini to orchestrate, validate, enrich, or route telemetry-related data where the required transport and payload are supported, while keeping REST management calls separate from OTLP ingestion.
Implementation sequence
Honeycomb trigger notifications
Honeycomb supports webhook-style notifications for selected alerting and trigger use cases. These notifications do not represent a general webhook for every Honeycomb event or resource change.
Martini implementation pattern
Martini implementation pattern: expose a Martini REST API or webhook workflow, authenticate and validate the notification, check for duplicate trigger deliveries, enrich the alert with ownership data, and forward it to an incident or collaboration platform.
Implementation sequence
Batch event ingestion
Honeycomb supports APIs for sending multiple events in one request. Batch ingestion is useful for source records read from files, databases, queues, or business applications, but request and event limits must be confirmed for the selected endpoint.
Martini implementation pattern
Martini implementation pattern: collect eligible source items, transform them into Honeycomb events, group them within documented limits, submit the batch, and separate successful items from transient and permanent failures.
Implementation sequence
Honeycomb query APIs
Honeycomb provides APIs for submitting queries and retrieving query results. Query execution may be asynchronous or require polling depending on the endpoint and API version.
Martini implementation pattern
Martini implementation pattern: schedule or trigger a workflow, submit a query with its environment, dataset, time range, and filters, poll when required, then apply thresholds and deliver a report or downstream action.
Implementation sequence
Common Honeycomb integration patterns
Pattern 1: Send deployment events to Honeycomb
When to use this pattern
Use this pattern when deployment metadata from GitHub, GitLab CI/CD, Jenkins, or another delivery system must be correlated with Honeycomb telemetry. The workflow standardizes service, version, environment, region, timestamp, status, and owner fields before ingestion.
Integration direction
Example Mapping
| Honeycomb Field | Canonical Field | Target Field |
|---|---|---|
| repository | source.repository | deployment.repository |
| commit_sha | deployment.version | deployment.version |
| environment | deployment.environment | deployment.environment |
| status | deployment.status | deployment.status |
Martini implementation pattern
Martini receives or retrieves deployment data, validates required fields, normalizes timestamps and names, applies an environment routing rule, and submits a Honeycomb event or batch. It records the source identifier and routes schema failures separately from transient API failures.
Martini capabilities used
- REST API creation
- API consumption
- workflows
- data mapping
- validation
- business rules
- error handling
Pattern 2: Send Honeycomb trigger notifications to incident management
When to use this pattern
Use this pattern when selected Honeycomb trigger notifications should create or update incidents in PagerDuty, ServiceNow, or Jira. It is appropriate for alert enrichment, ownership routing, and duplicate suppression.
Integration direction
Example Mapping
| Honeycomb Field | Canonical Field | Target Field |
|---|---|---|
| trigger_id | alert.source_id | correlation_id |
| trigger_name | alert.title | short_description |
| severity | alert.priority | impact_or_priority |
| service | service.name | configuration_item |
Martini implementation pattern
Martini receives the webhook-style notification, validates its structure, checks a stored notification or trigger identifier, enriches the message with service ownership when available, and performs an incident create-or-update operation. Retries apply only to transient downstream or network failures.
Martini capabilities used
- webhook consumption
- REST API creation
- workflows
- data mapping
- idempotency rules
- error handling
Pattern 3: Schedule Honeycomb reliability reports
When to use this pattern
Use this pattern for daily or periodic SLO summaries, error-rate checks, missing-telemetry checks, or environment-specific operational reports. The workflow can route different outcomes to Slack, Microsoft Teams, email, ServiceNow, or another API.
Integration direction
Example Mapping
| Honeycomb Field | Canonical Field | Target Field |
|---|---|---|
| query_id | report.query_id | message.reference |
| time_range | report.period | message.period |
| error_rate | reliability.error_rate | message.error_rate |
| slo_status | reliability.slo_status | message.status |
Martini implementation pattern
A Martini scheduler starts the workflow, which submits a scoped Honeycomb query and polls when necessary. It applies thresholds and business rules, creates a concise report, and routes abnormal results to an operational channel while logging query and delivery outcomes.
Martini capabilities used
- scheduled workflows
- API consumption
- query orchestration
- data mapping
- business rules
- monitoring
- error handling
Pattern 4: Batch operational events into Honeycomb
When to use this pattern
Use this pattern when records from a database, flat file, queue, or business application should become Honeycomb events for transaction, job, customer-impact, or integration-failure analysis.
Integration direction
Example Mapping
| Honeycomb Field | Canonical Field | Target Field |
|---|---|---|
| transaction_id | operation.id | transaction_id |
| job_status | operation.status | job_status |
| completed_at | event.timestamp | timestamp |
| customer_segment | customer.segment | customer_segment |
Martini implementation pattern
Martini reads source records, transforms them into a stable Honeycomb event schema, groups them within documented limits, and submits batch requests. Partial failures are split from successful items; transient failures are retried and permanent validation errors are retained for reconciliation.
Martini capabilities used
- database connectivity
- file or queue ingestion
- workflows
- batch orchestration
- data mapping
- validation
- retry handling
Applications commonly integrated with Honeycomb
Honeycomb can be integrated with observability, delivery, collaboration, and service-management products to correlate telemetry with operational activity. Martini can mediate these flows through REST APIs, selected webhook notifications, scheduled workflows, mapping, validation, and controlled error handling.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| OpenTelemetry Collector | Route traces, metrics, and logs through a standardized telemetry pipeline into Honeycomb. | OpenTelemetry Collector → Honeycomb | Use Martini where orchestration, validation, enrichment, or routing is required around the telemetry flow; use Honeycomb-supported OTLP transport for the telemetry payload itself. |
| Kubernetes | Correlate cluster, workload, and application telemetry with Honeycomb observability data. | Kubernetes → OpenTelemetry tooling → Honeycomb | Receive deployment or workload metadata from Kubernetes tooling, map it to Honeycomb event fields, and submit events through the Honeycomb ingestion API while telemetry pipelines use the appropriate OpenTelemetry path. |
| AWS CloudWatch | Combine AWS infrastructure signals and operational events with application telemetry in Honeycomb. | AWS CloudWatch → Martini → Honeycomb | Use a Martini workflow to retrieve or receive selected CloudWatch data, normalize timestamps and dimensions, apply field rules, and send compliant Honeycomb events. |
| GitHub | Associate commits, pull requests, and deployments with Honeycomb telemetry and change events. | GitHub → Martini → Honeycomb | Expose a Martini endpoint or consume GitHub APIs, validate deployment metadata, map repository and commit fields into a deployment-event model, and post the result to the target Honeycomb environment and dataset. |
| PagerDuty | Create or enrich incidents from selected Honeycomb trigger notifications. | Honeycomb → Martini → PagerDuty | Receive the Honeycomb notification, validate and deduplicate its trigger identifier, enrich it with ownership data when available, and call PagerDuty’s API with retry handling. |
| Slack | Deliver query summaries, trigger notifications, and operational reports to collaboration channels. | Honeycomb → Martini → Slack | Schedule a Honeycomb query or receive a selected notification, transform the result into a concise message, apply routing rules, and send it to Slack through its supported API or webhook. |
| ServiceNow | Create or update incidents and service-management records from Honeycomb alerts and reliability findings. | Honeycomb → Martini → ServiceNow | Receive or retrieve Honeycomb data, map service and severity fields to ServiceNow, use an idempotency key for incident upserts, and route permanent failures for review. |
| Jira | Create or update engineering issues for recurring Honeycomb alerts or reliability findings. | Honeycomb → Martini → Jira | Run a query or receive a trigger notification, apply threshold and deduplication rules, transform the result into Jira fields, and call Jira’s API with controlled retries. |
How to build a Honeycomb integration in Martini
Objective
Establish the Honeycomb API configuration and protect credentials for each deployment environment.
Instructions in Martini
- Use the Honeycomb API endpoint required by the workflow
- Store the X-Honeycomb-Team value in Martini secrets or protected environment configuration
- Use separate credentials for development, testing, and production
- Restrict key permissions to the required Honeycomb operations
Objective
Select the event, webhook, schedule, or upstream API request that should start the integration.
Instructions in Martini
- Use a Martini REST API or webhook workflow for selected Honeycomb trigger notifications
- Use a scheduler for recurring query and reporting workflows
- Use an upstream application event for deployment or business-event ingestion
- Define the expected payload and correlation identifier
Objective
Obtain Honeycomb events, query results, trigger notifications, or upstream records required by the flow.
Instructions in Martini
- Call the documented Honeycomb REST endpoint
- Handle pagination or continuation tokens where provided
- Poll asynchronous query operations when required
- Preserve source identifiers and response metadata
Objective
Coordinate validation, enrichment, routing, Honeycomb calls, and downstream operations in a maintainable workflow.
Instructions in Martini
- Separate ingestion, query, notification, and administrative paths
- Apply conditional routing by environment, service, severity, or result
- Control concurrency for high-volume event flows
- Use reusable services for repeated request and response handling
Objective
Convert source data into Honeycomb event, query, notification, or downstream application models.
Instructions in Martini
- Normalize timestamps and field types
- Map service, environment, region, version, and correlation fields consistently
- Keep Honeycomb-specific mappings isolated from canonical models
- Batch events only within documented size and count limits
Objective
Enforce data quality, routing, thresholds, and duplicate-handling decisions before side effects occur.
Instructions in Martini
- Validate required fields and permitted values
- Apply query thresholds and alert-routing rules
- Derive deterministic identifiers where supported
- Suppress repeated notifications when the source identifier was already processed
Common Honeycomb data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Environments | Organize telemetry, API access, datasets, and configuration in isolated Honeycomb spaces. | Martini, deployment platforms, service-management systems | Martini includes the environment context in API requests, keeps environment-specific credentials separate, and applies routing rules by environment. |
| Datasets | Provide logical collections for Honeycomb observability events, particularly in the classic ingestion model. | Martini, applications, reporting and operational systems | Martini maps source event categories to the appropriate dataset and validates required naming and payload conventions before ingestion. |
| Events | Represent telemetry or operational records with fields such as service names, timestamps, attributes, and measures. | Honeycomb, OpenTelemetry pipelines, operational applications | Martini transforms source records into stable event schemas, normalizes timestamps and types, batches eligible events, and separates failed items. |
| Queries | Define analytical requests used to explore Honeycomb event data and evaluate operational conditions. | Martini, reporting tools, Slack, ServiceNow, Jira | Martini submits query definitions, supplies time ranges and filters, and manages asynchronous execution or polling when required. |
| Query results | Return analytical data used for reports, threshold checks, health summaries, and workflow decisions. | Slack, Microsoft Teams, ServiceNow, PagerDuty, Jira | Martini parses result responses, applies business rules, maps summaries to target models, and records query execution outcomes. |
| Triggers | Evaluate alerting conditions and send selected notifications to configured destinations. | Martini, PagerDuty, ServiceNow, Slack, Jira | Martini receives supported trigger notifications, validates and deduplicates identifiers, enriches context, and forwards the result to downstream systems. |
Authentication and security considerations
API-key authentication
Honeycomb APIs generally use the X-Honeycomb-Team request header. Key scope and permissions can vary by environment, team, endpoint, and API-key type.
Credential protection
- Store Honeycomb keys in Martini secrets or protected environment configuration.
- Use separate credentials for development, testing, and production.
- Grant only the permissions required by each workflow.
- Do not place keys in payloads, mappings, source control, or logs.
Telemetry protection
Review telemetry fields for sensitive or personally identifiable information. Apply Honeycomb access, retention, and environment controls appropriate to the data being transmitted.
Operational considerations for Honeycomb integrations
Throughput and rate limits
Confirm Honeycomb quotas, request-size limits, event limits, and payload-size limits for the selected endpoint. Prefer batch ingestion where appropriate, control concurrency, and use exponential backoff for throttling responses.
Pagination and asynchronous queries
Query and administrative endpoints may paginate results or require polling. Persist the last successful page or cursor and do not assume that a query result is immediately available.
Idempotency and partial failures
Use stable event or notification identifiers where supported. For batch requests, separate successful items from transient and permanent failures, retry only eligible items, and preserve failed source data for reconciliation.
Schema and testing
Keep field names and types consistent, isolate Honeycomb-specific mappings, monitor API changes, and test payloads against non-production environments before release.
Monitoring
Track authentication failures, permission errors, invalid schemas, rate limits, timeouts, query failures, duplicate notifications, and downstream delivery outcomes in Martini workflow logs.
Why use Martini instead of scripts or point-to-point integrations?
Orchestrate more than one API call
Martini coordinates Honeycomb ingestion, queries, trigger notifications, enrichment, and downstream actions in a single maintainable workflow instead of scattering logic across scripts.
Separate mapping from business rules
Canonical models, field transformations, validation, threshold decisions, and routing rules can be managed explicitly and reused across deployment, alerting, reporting, and batch-ingestion flows.
Improve reliability
Workflows can distinguish transient failures from invalid data, apply controlled retries, handle pagination and polling, suppress duplicates, and preserve failed items for investigation.
Expose controlled APIs
Martini can expose REST endpoints for deployment events or Honeycomb notifications, providing a governed boundary for authentication, validation, enrichment, and downstream delivery.
Frequently asked questions
Honeycomb can be integrated through its REST APIs for event ingestion, batch events, queries, query results, environments, datasets, triggers, SLOs, and administration. It also supports OpenTelemetry ingestion through supported OTLP transports and selected webhook-style trigger notifications. Enterprise workflows can use these mechanisms to send telemetry, retrieve analytical results, and route alerts.
Yes. Martini can integrate with Honeycomb by consuming its REST APIs, sending mapped individual or batch events, using supported OpenTelemetry ingestion paths where applicable, querying Honeycomb data, and receiving selected trigger notifications through a Martini REST API or webhook workflow.
No. A dedicated Honeycomb connector is not required. Martini can use Honeycomb’s confirmed native REST APIs, supported OpenTelemetry ingestion methods, API-key authentication, and selected webhook-style notifications to implement the integration.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Honeycomb. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Honeycomb, cloud infrastructure, or other third-party systems based on subscription, usage, and deployment model.
Use Honeycomb REST APIs for event ingestion, batch events, queries, query results, and resource administration. Use OpenTelemetry ingestion for traces, metrics, and logs through the supported OTLP configuration. Use webhook-style notifications only for the selected trigger and alerting scenarios Honeycomb supports.
Honeycomb can send webhook-style notifications for selected trigger and alerting use cases, which Martini can receive through an exposed REST API or webhook workflow. This should not be treated as a universal outbound stream of every Honeycomb event or resource change.
Martini can run event-driven, scheduled, or batch workflows. It can submit source data as Honeycomb events, query Honeycomb and retrieve results, or receive selected trigger notifications. Pagination, asynchronous query polling, stable identifiers, and checkpointing should be included where the endpoint requires them.
Martini maps source fields into stable Honeycomb event or downstream models, validates required values, and applies routing and threshold rules. Workflows can retry transient network, throttling, and service failures, while permanent schema errors and partial batch failures are routed for review. Stable notification identifiers can support duplicate suppression.
Related Martini documentation
Notifications
Workflows
Connect Honeycomb with Martini
Use Martini to orchestrate Honeycomb APIs, OpenTelemetry-related workflows, batch event ingestion, query reporting, and selected trigger notifications across your enterprise systems.