Ellipse Gradient for Header

Harness Integration Guide

Integrate Harness with enterprise systems through REST APIs, configured webhook triggers, notifications, and Martini workflows for deployment orchestration and status synchronization.

Harness integration options at a glance

Harness provides REST APIs for querying and managing platform resources, starting pipeline executions, inspecting execution status, and working with projects, services, environments, connectors, and related objects. Configured webhook triggers allow external systems to start pipelines with branch, tag, commit, event, or custom input values. Harness notifications can report selected pipeline and execution events, although coverage depends on the configured channel and event type. Martini can consume these APIs, receive applicable webhook or notification requests, expose controlled APIs for deployment requests, and orchestrate polling, validation, mapping, retries, and downstream updates. Harness API keys are passed through the x-api-key header and should be stored as environment-specific secrets.

Integration pointSupported by Harness?Common use casesHow Martini supports it
REST APIsYesManage and query Harness resources, retrieve pipelines and executions, start pipeline executions, inspect status, and work with projects, services, environments, and connectors.Martini can consume Harness REST APIs from workflows, map request and response data, apply business rules, and expose reusable API-led orchestration.
WebhooksLimitedConfigured Harness webhook triggers allow external systems to start pipelines and provide branch, tag, commit, event, or custom input values.Martini can send requests to Harness trigger endpoints or receive applicable Harness webhook-style notifications through exposed APIs and workflows.
Outbound callbacks and notificationsLimitedHarness notifications can report selected pipeline or execution events to configured destinations; coverage depends on the channel, event type, and module.Martini can receive applicable notification requests, normalize event payloads, and supplement notifications with REST API status retrieval.
Pipeline execution APIsYesStart asynchronous pipeline executions, pass runtime inputs, capture execution identifiers, and retrieve execution details and status.Martini workflows can invoke the execution API, persist correlation data, poll at controlled intervals, apply timeout rules, and update downstream systems.
AuthenticationYesHarness REST API requests generally use an API key in the x-api-key header and scoped account, organization, and project identifiers.Martini can store API keys and identifiers in secure environment configuration and apply them to outbound API requests without embedding secrets in workflows.
SDKsLimitedHarness provides REST documentation and examples, but a universally supported vendor-maintained SDK strategy for every resource was not confirmed.Martini should use REST API consumption as the portable approach, with custom JVM-compatible logic only where a specific implementation requires it.
GraphQL APIsNot confirmedA generally available public Harness GraphQL API was not confirmed for enterprise integration use.Martini can consume GraphQL APIs generally, but Harness integrations should use the confirmed REST mechanisms instead.
SOAP APIsNot confirmedA public Harness SOAP API was not confirmed.Martini supports SOAP consumption generally, but no SOAP-based Harness integration should be assumed.

How Harness exposes data and business events

Harness REST APIs

Harness REST APIs are the primary integration mechanism for managing and querying platform resources, starting pipeline executions, retrieving execution status, and working with projects, services, environments, connectors, and other resources. Requests commonly require an accountIdentifier and may also require organization and project identifiers.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates with an x-api-key header stored in secure configuration, builds the resource-specific request, validates the response, maps Harness data to a canonical model, and persists correlation or checkpoint data for later processing.

Implementation sequence

Authenticate with the configured Harness API key
Build the request with account, organization, and project scope
Call the required Harness REST operation
Validate the response and map the resource data
Persist identifiers and checkpoints for downstream processing

Pipeline execution APIs

Harness exposes API operations for starting pipelines with runtime inputs and retrieving execution details. Starting a pipeline is asynchronous, so the initial response does not necessarily represent deployment completion.

Martini implementation pattern

Martini implementation pattern: expose or receive a deployment request, validate service and environment policy, invoke the Harness pipeline execution API, store the returned execution identifier, and poll or process selected notifications until a defined terminal state or timeout is reached.

Implementation sequence

Receive the deployment request
Validate service, environment, version, and approval state
Start the Harness pipeline with runtime inputs
Store the returned execution identifier
Poll execution status at a controlled interval
Map the terminal state and update the requesting system

Harness webhook triggers

Harness supports webhook-triggered pipeline execution for configured pipelines. Incoming requests can provide source branch, tag, commit, event, or custom input values, but this mechanism is a configured trigger rather than a universal event stream for all Harness resources.

Martini implementation pattern

Martini implementation pattern: Martini can produce a validated request for a Harness trigger endpoint or receive related upstream source events and route them to Harness. It can also correlate the resulting pipeline execution and apply duplicate prevention before triggering a release.

Implementation sequence

Receive or identify the supported source event
Validate the event and release parameters
Construct the configured Harness trigger request
Send the request to the Harness trigger endpoint
Store the correlation and execution reference
Reconcile execution status through the Harness API

Harness notifications

Harness supports notifications for selected pipeline and execution events through configured channels and destinations. Event availability and payloads depend on the Harness module, event type, and notification configuration, so notifications should not be treated as complete object-change coverage.

Martini implementation pattern

Martini implementation pattern: expose a secured endpoint for applicable notification requests, validate the expected shape and event identity, map the notification to a canonical deployment event, and retrieve current execution state from Harness when final status matters.

Implementation sequence

Receive the configured Harness notification
Validate the event shape and replay controls
Extract the pipeline and execution references
Retrieve current execution state when required
Map the event to the target system model
Apply idempotent downstream updates

Common Harness integration patterns

Pattern 1: Link approved changes to Harness deployments

When to use this pattern

Use this pattern when ServiceNow or Jira approval must control when a Harness pipeline can start and when the resulting execution status must be written back to the change or issue. It is appropriate for release governance, approval validation, and auditable deployment orchestration.

Integration direction
ServiceNow or Jira
Martini
Harness
ServiceNow or Jira
Example Mapping
Harness FieldCanonical FieldTarget Field
change or issue identifierreleaseRequestIdHarness correlation reference
service identifierserviceIdHarness service reference
target environmentenvironmentIdHarness environment reference
approved versionreleaseVersionpipeline runtime input
Martini implementation pattern

A Martini workflow receives or retrieves approved changes, validates approval state and release policy, maps the request to Harness pipeline inputs, starts the asynchronous execution, and persists the execution identifier. It then polls execution status, applies bounded retries and timeout rules, and updates the originating system idempotently.

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

Pattern 2: Process source-control events into controlled deployments

When to use this pattern

Use this pattern when GitHub or GitLab events should initiate a configured Harness pipeline while Martini adds validation, enrichment, status reconciliation, or downstream notifications. Harness webhook triggers remain limited to configured pipelines and supported event inputs.

Integration direction
GitHub or GitLab
Harness
Martini
Example Mapping
Harness FieldCanonical FieldTarget Field
repository and revisionsourceRevisionpipeline branch, tag, or commit input
event typesourceEventTypeHarness trigger event input
repository URLsourceRepositorypipeline or connector context
release identifiercorrelationIdMartini execution checkpoint
Martini implementation pattern

The source system invokes a Harness trigger for supported events. Martini can receive selected notifications or query the Harness API to enrich execution data, normalize status, prevent duplicate downstream processing, and route failures to operational systems.

Martini capabilities used
  • webhook consumption
  • API consumption
  • workflows
  • data mapping
  • correlation
  • error handling

Pattern 3: Normalize deployment status for operations

When to use this pattern

Use this pattern when Harness execution outcomes must be delivered to Slack, PagerDuty, ServiceNow, Jira, or another operational system with a consistent status model. It is useful when notification coverage is partial or when final execution state must be confirmed through polling.

Integration direction
Harness
Martini
Slack, PagerDuty, ServiceNow, or Jira
Example Mapping
Harness FieldCanonical FieldTarget Field
pipeline execution statusdeploymentStatusincident or change status
pipeline identifierdeploymentDefinitionIdexternal deployment reference
failure detailsfailureReasonincident summary or work note
execution timestampcompletedAtcompletion or event timestamp
Martini implementation pattern

A scheduled or notification-triggered Martini workflow retrieves current Harness execution details, maps Harness states and failure information to a canonical operational event, applies alerting and duplicate rules, and calls the target product API. Retries and partial-update recovery are included for downstream failures.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • data mapping
  • business rules
  • retry handling
  • monitoring

Pattern 4: Expose a deployment orchestration API

When to use this pattern

Use this pattern when internal applications need a controlled API for starting Harness pipelines without embedding Harness credentials, account scope, pipeline identifiers, or release policy in each client.

Integration direction
Internal application
Martini
Harness
Kubernetes or Amazon Web Services
Example Mapping
Harness FieldCanonical FieldTarget Field
requested serviceserviceIdHarness service reference
requested targetenvironmentIdHarness environment reference
artifact or image versionreleaseVersionpipeline runtime input
request identifiercorrelationIdMartini and Harness execution tracking
Martini implementation pattern

Martini exposes a secured REST endpoint, validates the caller and request against service ownership and environment policy, invokes the relevant Harness pipeline, and returns a normalized pending or accepted response with correlation information. A follow-up workflow monitors the execution and publishes the terminal result.

Martini capabilities used
  • API exposure
  • authentication and authorization
  • workflows
  • API consumption
  • validation
  • business rules
  • error handling

Applications commonly integrated with Harness

Harness commonly participates in software delivery workflows that include source control, change governance, deployment targets, collaboration, and incident response. Martini can coordinate these systems when standard Harness APIs, configured triggers, notifications, and the adjacent product APIs need validation, transformation, correlation, or reliable status handling.

Application Scenario Direction Martini Pattern
GitHub Repository branches, tags, pull requests, and source revisions can drive controlled pipeline execution and deployment workflows. GitHub → Harness Use Harness webhook triggers for supported source events, or use Martini to enrich and validate release metadata before invoking Harness APIs. Martini can also reconcile execution status for downstream systems.
GitLab Merge, branch, tag, and repository events can initiate CI/CD workflows and provide source revision information for deployments. GitLab → Harness Route supported GitLab events to a configured Harness trigger, or have Martini validate release inputs and call the Harness pipeline execution API. Store the Harness execution identifier for later status checks.
Jira Deployment outcomes and approvals can be associated with Jira issues, releases, and change governance processes. Jira → Martini → Harness → Martini Receive or retrieve approved Jira changes, validate the service, environment, version, and approval state, start the Harness pipeline, and update the Jira issue using an idempotent correlation identifier.
ServiceNow ServiceNow change approvals and release governance can be connected to Harness deployment execution and status. ServiceNow → Martini → Harness → Martini Use a Martini workflow to retrieve or receive approved changes, validate policy and scope, invoke Harness with runtime inputs, poll execution status, and write the terminal result back to the originating change.
Kubernetes Harness delivery pipelines can deploy workloads to Kubernetes environments and provide execution status for release processes. Martini → Harness → Kubernetes Expose a Martini deployment API that validates service ownership, target environment, and image or artifact version before starting the associated Harness pipeline. Normalize the resulting execution state for the requesting application.
Amazon Web Services Harness pipelines can coordinate deployment or provisioning workflows targeting AWS resources and environments. Martini → Harness → Amazon Web Services Accept a controlled deployment request through Martini, apply environment and release policy checks, invoke the Harness pipeline, and monitor the asynchronous execution through its REST API.
Slack Deployment approvals, completion messages, and failure notifications can be delivered to engineering channels. Harness → Martini → Slack Retrieve selected Harness execution or notification data, map it to a concise operational message, and call Slack APIs from a Martini workflow with duplicate suppression and failure handling.
PagerDuty Failed deployments or selected operational events can be routed into incident response workflows. Harness → Martini → PagerDuty Use Martini to reconcile terminal Harness execution states, apply alerting rules, and send normalized incident events to PagerDuty while preserving the Harness execution and release correlation IDs.

How to build a Harness integration in Martini

Objective

Establish the Harness API connection with environment-specific credentials and scope rather than embedding authentication details in workflow logic.

Instructions in Martini

  • Configure the Harness API base URL and required accountIdentifier, orgIdentifier, and projectIdentifier values
  • Store the API key in Martini secrets or secure environment configuration
  • Use a service account with minimum required Harness RBAC permissions
  • Mask authorization headers and sensitive values in logs

Objective

Select the event, API request, notification, or schedule that should initiate the integration behavior.

Instructions in Martini

  • Use a Martini API for internal deployment requests
  • Use a webhook or start trigger for inbound events where applicable
  • Use a scheduler for execution reconciliation and complete synchronization
  • Treat Harness notifications as selected-event signals rather than universal object events

Objective

Obtain the Harness resource or execution information required by the business process.

Instructions in Martini

  • Call the relevant Harness REST API operation
  • Receive and validate configured webhook or notification requests
  • Capture pipeline execution identifiers after starting asynchronous work
  • Implement resource-specific pagination where collection endpoints require it

Objective

Coordinate validation, Harness API calls, status checks, and downstream updates in a maintainable Martini workflow.

Instructions in Martini

  • Validate account, organization, project, pipeline, service, and environment scope
  • Apply approval, ownership, and release policy rules before execution
  • Poll asynchronous pipeline executions at controlled intervals
  • Define terminal states, timeout behavior, and compensation for partial updates

Objective

Convert Harness payloads and external release requests into a canonical model suitable for downstream systems.

Instructions in Martini

  • Map pipeline inputs to a canonical deployment request
  • Normalize execution states and timestamps
  • Transform failure details into change, incident, or collaboration messages
  • Preserve Harness identifiers and correlation IDs for traceability

Objective

Deliver execution requests and outcomes to Harness and connected enterprise applications with duplicate-safe behavior.

Instructions in Martini

  • Start the Harness pipeline only after validation succeeds
  • Update ServiceNow, Jira, Slack, PagerDuty, or internal applications using their supported APIs
  • Make downstream updates idempotent using a business correlation identifier
  • Record the relationship between the request and Harness execution

Common Harness data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
PipelinesVersioned delivery or automation definitions containing stages, services, environments, strategies, and execution logic.ServiceNow, Jira, GitHub, GitLab, internal release portalsMartini retrieves or invokes pipeline definitions through REST APIs, validates identifiers and inputs, and uses them as the basis for controlled orchestration.
Pipeline executionsIndividual pipeline runs with status, inputs, timestamps, stages, and execution details.ServiceNow, Jira, Slack, PagerDuty, internal deployment portalsMartini stores execution identifiers, polls or receives selected notifications, maps states to a canonical status model, and applies timeout, retry, and duplicate-handling rules.
ServicesDeployable application or workload definitions used in delivery pipelines.Internal service catalogs, Jira, ServiceNow, KubernetesMartini can retrieve service metadata, validate service ownership and deployment requests, and map service identifiers into downstream governance workflows.
EnvironmentsDeployment targets or logical infrastructure contexts associated with services and pipeline stages.ServiceNow, internal release portals, Kubernetes, Amazon Web ServicesMartini validates target environment and policy information before starting a pipeline and normalizes environment identifiers for downstream systems.
ConnectorsConfigured connections to source repositories, cloud providers, container registries, Kubernetes clusters, and ticketing platforms.Internal governance systems, audit stores, service catalogsMartini can query connector metadata where permitted, avoid exposing credentials, and synchronize approved non-secret configuration details for governance purposes.
ProjectsOrganizational containers that group Harness resources and apply permissions, settings, and governance.Identity governance, service catalogs, reporting storesMartini can retrieve project context and use account, organization, and project identifiers to scope API calls and enforce integration routing rules.

Authentication and security considerations

API-key authentication

Harness REST API requests generally use an API key in the x-api-key header. Martini should keep the key in secure environment configuration or secrets management rather than in workflow source, query strings, mappings, or logs.

Scope and permissions

Requests commonly require an accountIdentifier and may also require organization and project identifiers. Harness RBAC, users, groups, roles, resource groups, and service accounts control what the credential can access.

Environment separation

  • Prefer service account credentials for unattended workflows.
  • Use separate credentials for development, testing, and production.
  • Grant only the permissions required to query resources or start defined pipelines.
  • Mask authorization headers and sensitive request values in operational logs.

Operational considerations for Harness integrations

Asynchronous execution

Starting a Harness pipeline does not mean deployment work has completed. Store the execution identifier, poll at a controlled interval or process applicable notifications, and define terminal states and timeout behavior.

Throttling and pagination

Confirm limits for the relevant Harness account, region, API family, and subscription tier. Use backoff for transient failures, avoid aggressive polling, and implement pagination according to each specific resource operation rather than assuming a universal format.

Idempotency and webhook controls

Retries after uncertain responses can start duplicate executions. Persist a business correlation identifier, check for an existing execution where appropriate, record notification identifiers and timestamps, and make downstream updates idempotent.

Schema and testing

Harness contains module-specific and versioned API areas. Validate pipeline, execution, service, environment, and connector response schemas, avoid relying on undocumented fields, and maintain contract tests for critical pipeline-start and status operations.

Failure handling

  • Handle invalid API keys, insufficient RBAC permissions, and invalid account, organization, or project identifiers.
  • Route missing inputs, validation failures, execution failures, rate limits, and network timeouts through explicit error paths.
  • Do not treat a notification as proof of deployment success when final execution state can be queried.
  • Recover or reconcile partial downstream updates.

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

Orchestration beyond a script

Martini provides a maintainable workflow layer for validating release requests, invoking Harness APIs, monitoring asynchronous executions, applying business rules, and updating multiple enterprise systems. This avoids duplicating credentials, polling logic, and error handling across individual scripts.

Controlled APIs and reusable logic

Martini can expose a controlled API for internal applications that need to start Harness pipelines without embedding Harness credentials or release policy in each client. Common validation, mapping, correlation, and status logic can be reused across workflows.

Operational reliability

  • Centralize retries, timeouts, throttling, pagination, and duplicate prevention.
  • Keep environment-specific Harness credentials and identifiers outside workflow source.
  • Map Harness states into consistent models for change, incident, collaboration, and deployment systems.
  • Combine event-driven processing with scheduled reconciliation when notification coverage is incomplete.

Frequently asked questions

How can Harness be integrated with enterprise systems?

Harness can be integrated through its REST APIs, configured webhook-triggered pipeline endpoints, and selected notification or callback mechanisms. Enterprise workflows can retrieve Harness resources, start pipeline executions with runtime inputs, monitor asynchronous execution status, and connect outcomes to source control, change management, collaboration, incident response, cloud, and Kubernetes systems.

Can Martini integrate with Harness?

Yes. Martini can integrate with Harness by consuming its REST APIs, sending requests to configured webhook trigger endpoints, receiving applicable notification requests, exposing APIs for deployment orchestration, and coordinating validation, polling, mapping, retries, and downstream updates.

Do I need a connector to integrate Harness with Martini?

No. A dedicated Harness connector is not required. Martini can use Harness's confirmed native integration mechanisms, primarily REST APIs, API-key authentication, configured webhook triggers, and selected notification or callback endpoints.

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

Lonti does not charge an additional per-connector or per-vendor fee to integrate Harness with Martini. Integration use is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Harness, cloud infrastructure, or other third-party systems according to their subscriptions, usage, and deployment models.

Which Harness integration methods should architects use?

REST APIs should be the primary method for resource management, pipeline execution, and status retrieval. Configured webhook triggers are useful for starting selected pipelines from supported source events, while notifications can supplement status processing for selected pipeline or execution events. A generally available public Harness GraphQL or SOAP API was not confirmed.

Can Harness send events or webhooks to Martini?

Harness supports webhook-triggered pipeline execution and selected notification or callback patterns. Coverage depends on the configured trigger, event type, module, and destination; it should not be treated as a universal outbound event stream for every Harness object or field change. Martini can supplement event processing with API polling or scheduled reconciliation.

How does Martini synchronize Harness data?

Martini can retrieve pipelines, pipeline executions, services, environments, connectors, projects, and related resources through Harness REST APIs. For reliable synchronization, workflows should combine applicable notifications with scheduled reconciliation, resource-specific pagination, checkpoints, execution identifiers, and controlled polling for asynchronous pipeline runs.

How does Martini handle Harness mapping, errors, and duplicate executions?

Martini maps Harness payloads to canonical models and applies validation and business rules before writing to target systems. Workflows can use bounded retries, backoff, timeout handling, and error routing for rate limits, permissions, network failures, and pipeline failures. Correlation identifiers and persisted execution references help prevent duplicate pipeline starts and duplicate downstream updates.

Related Martini documentation

APIs

Triggers

Workflows

Security

Operations

Connect Harness with Martini

Use Martini to orchestrate Harness deployments, expose controlled APIs, synchronize execution status, and connect software delivery workflows with enterprise systems.

EXPLORE MARTINI
BOOK A DEMO