Ellipse Gradient for Header

Heroku Integration Guide

Integrate Heroku applications and platform resources with enterprise systems through the Heroku Platform API, selected App Webhooks, and Heroku Postgres connectivity.

Heroku integration options at a glance

Heroku’s primary integration surface is the versioned, JSON-based Platform API for Apps, Pipelines, Builds, Releases, Dynos, Add-ons, teams, and related resources. Martini can consume these REST endpoints with an API token or OAuth 2.0 credentials, follow pagination links, transform responses, and orchestrate downstream actions. Heroku App Webhooks provide notifications for selected lifecycle and platform events, while scheduled polling remains appropriate for unsupported or incomplete event coverage. Some build and deployment operations are asynchronous and require status monitoring. Where network access and credentials are available, Martini can also connect to Heroku Postgres through PostgreSQL rather than through the Platform API.

Integration pointSupported by Heroku?Common use casesHow Martini supports it
REST APIsYesThe versioned Heroku Platform API manages Apps, Pipelines, Builds, Releases, Dynos, Add-ons, teams, collaborators, domains, and related resources. It is the primary mechanism for synchronization and platform automation.Martini can consume REST endpoints, send the required media type and authorization headers, follow pagination links, map JSON responses, and orchestrate downstream workflows.
WebhooksLimitedHeroku App Webhooks provide notifications for selected app lifecycle and platform events involving resources such as Builds, Releases, Dynos, Config Vars, Domains, Collaborators, and Add-ons.Martini can expose a controlled API endpoint to receive webhook requests, validate them, retrieve the current resource, deduplicate events, and trigger downstream processing.
AuthenticationYesHeroku Platform API access supports bearer API tokens and OAuth 2.0 authorization-code flows. Effective access depends on user, team, app, and OAuth permissions.Martini can store credentials in protected configuration or secrets, apply authorization headers, and use least-privilege credentials for each workflow.
Bulk and asynchronous APIsLimitedBuild and deployment operations can be asynchronous and may require subsequent requests to monitor status. No general-purpose bulk resource update API was confirmed.Martini can retain operation identifiers, poll status with bounded retries, distinguish queued, running, successful, and failed states, and process large collections incrementally.
Database accessLimitedHeroku Postgres supports PostgreSQL connectivity for application data when credentials, SSL, network routing, and firewall access are available. This is separate from the Platform API.Martini can use SQL workflows and PostgreSQL connectivity to query, transform, validate, and export Heroku Postgres data.
File and artifact handlingLimitedHeroku supports deployment source artifacts and build inputs, while HTTP log drains can deliver operational streams. No general-purpose business attachment repository API was confirmed.Martini can orchestrate supported artifact or log-delivery interfaces, transform payloads, apply filtering, and route content to files or downstream APIs where required.
Scheduled synchronizationYesPolling is appropriate for resources and changes not covered by App Webhooks and for reconciliation of Apps, Builds, Releases, Dynos, Pipelines, and Add-ons.Martini can schedule workflows, store checkpoints, follow pagination, compare identifiers or timestamps, throttle requests, and recover from partial runs.

How Heroku exposes data and business events

Heroku REST APIs

The Heroku Platform API is a versioned JSON REST interface for managing and inspecting Apps, Pipelines, Builds, Releases, Dynos, Add-ons, teams, collaborators, and related resources. Collection responses may be paginated, and permissions depend on the authenticated user, team, app, and requested OAuth scope.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates with an API token or OAuth access token, calls the required Platform API endpoint, follows pagination links, maps the JSON response into a canonical model, applies business rules, and writes to downstream systems. For asynchronous Builds or Releases, the workflow retains the resource identifier and checks status until a defined terminal condition.

Implementation sequence

Authenticate with a protected API token or OAuth access token
Request the required Heroku resource
Follow pagination links for collection responses
Map Heroku JSON into the target data model
Apply ownership, status, and reconciliation rules
Persist the result and synchronization checkpoint

Heroku App Webhooks

Heroku App Webhooks provide HTTP notifications for selected app lifecycle and platform events, including certain Build, Release, Dyno, Config Var, Domain, Collaborator, and Add-on changes. Coverage is selective and does not represent a universal change-data-capture stream.

Martini implementation pattern

Martini implementation pattern: a Martini API receives the webhook, validates the configured authentication or verification controls, records an idempotency key, and starts a workflow. The workflow retrieves the current Heroku resource before transforming and routing it, because webhook payloads may be incomplete and delivery may be retried or duplicated.

Implementation sequence

Receive the Heroku webhook request
Validate the configured webhook authentication or verification controls
Persist the event or resource key for deduplication
Retrieve the current Heroku resource through the Platform API
Map and route the event to downstream systems
Record processing status and retry transient failures

Heroku asynchronous builds and releases

Some Heroku build and deployment activities are asynchronous. An initial request may return an operation or resource that must be monitored through later Platform API requests before the workflow can determine the final outcome.

Martini implementation pattern

Martini implementation pattern: a workflow starts or observes the operation, stores the returned Build or Release identifier, waits according to a bounded retry policy, polls the status, and emits a final success or failure result. The workflow should distinguish build completion from application health and expected dyno state.

Implementation sequence

Start or identify the Heroku Build or Release operation
Store the returned resource identifier
Wait using a bounded backoff interval
Retrieve the latest operation status
Apply terminal-state and timeout rules
Publish the final result or route an exception

Heroku Postgres

Heroku Postgres exposes application data through PostgreSQL connectivity when credentials, SSL, routing, and network access are configured. Database access is distinct from the Heroku Platform API and should be governed by database permissions and query controls.

Martini implementation pattern

Martini implementation pattern: a scheduled or API-triggered workflow opens a protected PostgreSQL connection, executes a constrained query or transaction, maps rows into a canonical structure, and writes to another database, file, or API. Credentials and sensitive fields remain in protected configuration and are excluded from logs.

Implementation sequence

Validate database connectivity and protected credentials
Open a PostgreSQL connection with appropriate SSL settings
Run a bounded query or transaction
Map and validate returned rows
Write the transformed data to the target
Close the connection and record processing metrics

Common Heroku integration patterns

Pattern 1: Synchronize Heroku application inventory

When to use this pattern

Use this pattern when operations or governance teams need a current inventory of Heroku Apps, Pipelines, Dynos, Add-ons, and ownership metadata. A scheduled reconciliation is appropriate because App Webhooks do not cover every resource or change.

Integration direction
Heroku
Martini
ServiceNow
Example Mapping
Heroku FieldCanonical FieldTarget Field
app.idapplication.externalIdServiceNow Configuration Item external ID
app.nameapplication.nameServiceNow Configuration Item name
app.region.namedeployment.regionServiceNow region
dynos.quantityruntime.instanceCountServiceNow instance count
Martini implementation pattern

A scheduled Martini workflow retrieves each resource collection, follows pagination, joins related Apps and Pipelines, and maps the result into ServiceNow inventory records. It uses stable identifiers for idempotent upserts, compares checkpoints to limit work, and routes permission or rate-limit failures through retry and exception handling.

Martini capabilities used
  • scheduled workflows
  • REST API consumption
  • pagination and checkpointing
  • data mapping
  • business rules
  • error handling

Pattern 2: Route Heroku deployment events

When to use this pattern

Use this pattern when engineering or operations teams need deployment notifications, change records, or monitoring annotations for selected Builds and Releases. Webhook coverage should be verified for the required event types before relying on event-driven processing.

Integration direction
Heroku
Martini
Slack
Example Mapping
Heroku FieldCanonical FieldTarget Field
build.statusdeployment.statusSlack message status
release.iddeployment.releaseIdSlack release identifier
app.nameapplication.nameSlack application name
build.source_blob.urldeployment.sourceReferenceSlack source reference
Martini implementation pattern

A Martini API receives the App Webhook, validates it, retrieves the latest Build or Release, and enriches the event with application metadata. Business rules classify failed, successful, and transitional states; duplicate keys suppress repeated notifications; transient Heroku or Slack failures use bounded retries.

Martini capabilities used
  • API exposure
  • webhook consumption
  • REST API enrichment
  • data transformation
  • conditional routing
  • idempotency and retries

Pattern 3: Monitor Heroku build and release completion

When to use this pattern

Use this pattern when a deployment process must distinguish an accepted build from a completed release. It is useful for change automation where downstream actions must wait for a terminal status rather than the initial asynchronous response.

Integration direction
Heroku
Martini
ServiceNow
Example Mapping
Heroku FieldCanonical FieldTarget Field
build.iddeployment.operationIdServiceNow change operation ID
build.statusdeployment.buildStatusServiceNow build status
release.versiondeployment.releaseVersionServiceNow release version
app.nameapplication.nameServiceNow application
Martini implementation pattern

Martini stores the Build or Release identifier, polls the Platform API with bounded backoff, and applies timeout and terminal-state rules. A successful build does not automatically imply healthy dynos, so the workflow can separately retrieve runtime state before closing or advancing the downstream change.

Martini capabilities used
  • workflow orchestration
  • asynchronous API processing
  • status polling
  • business rules
  • timeout handling
  • monitoring

Pattern 4: Export Heroku Postgres data

When to use this pattern

Use this pattern when selected application data must be exported to a reporting database, file destination, or external API, or when an approved API request should return data from Heroku Postgres.

Integration direction
Heroku Postgres
Martini
Amazon S3
Example Mapping
Heroku FieldCanonical FieldTarget Field
customer_idcustomer.externalIdexport.customerId
created_atcustomer.createdAtexport.createdAt
statuscustomer.statusexport.status
updated_atcustomer.updatedAtexport.updatedAt
Martini implementation pattern

A scheduled or API-triggered Martini workflow executes a bounded PostgreSQL query, validates and transforms rows, and writes the result to the target. It uses checkpoints or key ranges for incremental extraction, protects sensitive fields, and handles connection, query, and delivery failures without duplicating completed batches.

Martini capabilities used
  • SQL database connectivity
  • API-triggered workflows
  • data mapping
  • validation
  • incremental processing
  • error handling

Applications commonly integrated with Heroku

Heroku commonly participates in application delivery, operational governance, data, monitoring, and collaboration workflows. Martini can coordinate Heroku APIs, webhooks, PostgreSQL access, and downstream application APIs without embedding vendor-specific orchestration in individual scripts.

Application Scenario Direction Martini Pattern
Salesforce Synchronize Salesforce data with applications running on Heroku, commonly through Heroku Connect and Heroku Postgres, while coordinating validation or related enterprise workflows. Salesforce → Martini → Heroku Postgres Martini can call Salesforce APIs, query Heroku Postgres through PostgreSQL, apply validation and ownership rules, and route exceptions for review. Heroku Connect remains a possible synchronization component where appropriate.
GitHub Relate source-control changes to Heroku Builds and Releases and coordinate deployment status with engineering workflows. GitHub → Martini → Heroku A Martini workflow can receive or poll deployment-related information, enrich it with Heroku Build or Release resources, apply status rules, and publish results to engineering or governance systems.
PostgreSQL Exchange application data with Heroku Postgres using database connectivity where credentials, SSL, and network routing are available. Heroku Postgres → Martini → PostgreSQL Martini can run controlled SQL workflows, map selected rows into canonical structures, apply query and transaction rules, and write results to another database or API.
Amazon S3 Exchange exports, deployment-related artifacts, or application-generated files with object storage when the Heroku application or surrounding integration exposes the required interfaces. Heroku → Martini → Amazon S3 Martini can orchestrate an API- or file-based export, transform content, validate metadata, and deliver it to S3 or retrieve it for downstream processing. The exact artifact path depends on the Heroku application implementation.
Slack Notify engineering and operations teams about selected Builds, Releases, failures, or other Heroku lifecycle conditions. Heroku → Martini → Slack Martini receives a supported App Webhook, retrieves the current Heroku resource, suppresses duplicate notifications, formats a concise message, and calls Slack for delivery.
ServiceNow Synchronize Heroku application inventory, deployment information, incidents, or change records with enterprise operations. Heroku → Martini → ServiceNow A scheduled or webhook-triggered Martini workflow retrieves Apps, Releases, Builds, Dynos, and Add-ons, maps them to ServiceNow records, applies reconciliation rules, and handles API failures with retries.
Datadog Coordinate Heroku or application observability data with monitoring workflows and deployment annotations. Heroku → Martini → Datadog Martini can route selected lifecycle events or operational data to Datadog, enrich messages with Heroku resource details, and apply filtering and rate controls before delivery.
New Relic Correlate Heroku releases and application runtime activity with application performance monitoring workflows. Heroku → Martini → New Relic Martini can process selected deployment or operational notifications, map release identifiers and application metadata, and send controlled updates to New Relic or related operational systems.

How to build a Heroku integration in Martini

Objective

Establish controlled access to the Heroku Platform API or Heroku Postgres using credentials appropriate to the integration.

Instructions in Martini

  • Choose an API token or OAuth 2.0 flow based on delegation and scope requirements
  • Store tokens, OAuth credentials, and database credentials in protected Martini configuration or secrets
  • Configure Heroku API headers, including the required bearer authorization and API media type
  • For Heroku Postgres, confirm SSL, routing, firewall, and connection requirements

Objective

Select an event-driven, scheduled, or API-triggered entry point based on Heroku coverage and the required processing latency.

Instructions in Martini

  • Use a Martini API for supported Heroku App Webhooks
  • Use a scheduler for reconciliation or resources without adequate webhook coverage
  • Use an exposed Martini API when another system must request Heroku or PostgreSQL data
  • Avoid treating App Webhooks as complete change-data capture

Objective

Obtain the authoritative Heroku resource or database rows needed for processing.

Instructions in Martini

  • Call the Platform API for Apps, Builds, Releases, Dynos, Pipelines, or Add-ons
  • Follow collection pagination links rather than assuming a single response is complete
  • Retrieve the current resource after a webhook before applying irreversible actions
  • Use bounded SQL queries for Heroku Postgres extraction

Objective

Coordinate enrichment, asynchronous status checks, routing, and downstream calls in a maintainable Martini workflow.

Instructions in Martini

  • Store operation identifiers for asynchronous Builds or Releases
  • Use controlled concurrency and backoff for polling and transient failures
  • Join related Heroku resources when an event payload is incomplete
  • Persist checkpoints and event keys for restartability and deduplication

Objective

Convert Heroku JSON or PostgreSQL rows into a canonical model appropriate for the target application.

Instructions in Martini

  • Map stable Heroku identifiers, names, statuses, regions, versions, and timestamps
  • Normalize status values and deployment lifecycle states
  • Exclude Config Vars, tokens, and other sensitive values from ordinary payloads
  • Validate required fields before downstream writes

Objective

Enforce permissions, ownership, lifecycle, and delivery rules before creating or updating target records.

Instructions in Martini

  • Use least-privilege credentials and respect team and app visibility
  • Distinguish Build completion from Release completion and runtime health
  • Suppress duplicate webhook and polling results using stable resource keys
  • Apply timeout, terminal-state, and reconciliation policies

Common Heroku data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
AppsRepresent Heroku applications, including identity, region, stack, maintenance state, and related metadata.ServiceNow, asset inventories, governance platforms, monitoring systemsMartini retrieves Apps through REST workflows, normalizes identifiers and metadata, applies visibility and ownership rules, and performs idempotent upserts.
PipelinesGroup applications across development, staging, and production promotion flows.ServiceNow, deployment governance tools, reporting databasesMartini maps pipeline membership and environment relationships into a canonical delivery model and reconciles changes during scheduled synchronization.
BuildsTrack build executions, source artifacts, status, and associated application activity.GitHub workflows, Slack, ServiceNow, monitoring platformsMartini can receive selected webhook notifications, retrieve the complete Build resource, classify status, and route notifications or records.
ReleasesRepresent deployments or configuration changes that create a new application release.ServiceNow, Slack, Datadog, New RelicMartini enriches release events with app and build data, applies ordering and duplicate controls, and publishes deployment information.
DynosDescribe app process instances, process types, quantities, sizes, and runtime state.ServiceNow, monitoring platforms, operational dashboardsMartini polls or receives selected notifications, maps runtime state, and applies reconciliation rules to avoid treating transient states as final.
Add-onsRepresent provisioned backing services attached to an app, including Heroku Postgres or third-party services.ServiceNow, asset inventories, governance databasesMartini retrieves Add-ons with app context, protects sensitive configuration, and maps service ownership and lifecycle information.

Authentication and security considerations

API credentials

Heroku supports bearer API tokens and OAuth 2.0 for Platform API access. Use the least-privileged practical scope and account or team permissions for each workflow.

Secrets and sensitive data

Store API tokens, OAuth credentials, and PostgreSQL connection information in Martini secrets or protected environment configuration. Config Vars may contain credentials and should not be copied into logs, notifications, or ordinary integration payloads.

Webhook protection

Validate Heroku App Webhook requests according to the configured authentication and verification controls. Record an idempotency key before processing because webhook delivery can be retried or duplicated.

Database security

Heroku Postgres integrations should account for SSL, credential rotation, network routing, firewall controls, query permissions, and transaction boundaries.

Operational considerations for Heroku integrations

Rate limits and retries

Use controlled request rates, bounded concurrency, and exponential or scheduled backoff for transient HTTP failures. Avoid aggressive polling when a supported webhook can provide the required signal.

Pagination and checkpoints

Follow Heroku pagination links for Apps, Builds, Releases, Dynos, and Add-ons. Store checkpoints so interrupted synchronization can resume without reprocessing the full collection.

Asynchronous operations

Builds and deployments may require status polling. Distinguish queued, running, successful, and failed states, and do not equate build success with application health or expected dyno state.

Idempotency and ordering

Use stable event or resource keys to prevent duplicate downstream actions. Tolerate eventual consistency when Release, Build, and runtime information becomes visible at different times.

Schema and testing

Use tolerant mappings, validate required fields, and test changes in API representations and Heroku Postgres schemas. Separate deployment artifacts, build completion, release creation, and runtime state in business rules.

Log delivery

HTTP log drains can be high volume and should be filtered, rate-controlled, and retained deliberately. They are operational streams rather than guaranteed business-event ledgers.

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

Centralized orchestration

Martini coordinates Heroku APIs, selected webhooks, PostgreSQL queries, and downstream applications in workflows rather than scattering logic across independent scripts.

Reusable integration logic

Authentication, pagination, mapping, validation, asynchronous status monitoring, retry behavior, and idempotency controls can be implemented as maintainable workflow assets.

Controlled APIs

Martini can expose a controlled API façade for approved Heroku operations or data access, applying authorization, validation, transformation, and business rules before invoking downstream systems.

Operational reliability

Workflow-level error handling, checkpoints, monitoring, and environment-specific secrets provide a clearer operating model than point-to-point scripts that each implement their own failure and security behavior.

Frequently asked questions

How can Heroku be integrated with enterprise systems?

Heroku can be integrated primarily through its versioned Platform API, which exposes Apps, Pipelines, Builds, Releases, Dynos, Add-ons, teams, and related resources as JSON REST endpoints. Selected App Webhooks can provide lifecycle notifications, while scheduled polling supports reconciliation and changes without webhook coverage. Heroku Postgres can also be accessed through PostgreSQL when credentials and network connectivity are available.

Can Martini integrate with Heroku?

Yes. Martini can consume the Heroku Platform API using API tokens or OAuth 2.0, receive selected Heroku App Webhooks through a Martini API, schedule synchronization workflows, and connect to Heroku Postgres through PostgreSQL where the required access is configured.

Do I need a connector to integrate Heroku with Martini?

No. A dedicated Heroku connector is not required. Martini can integrate using Heroku’s confirmed native mechanisms, including the Platform API, selected App Webhooks, API token or OAuth authentication, and PostgreSQL connectivity for Heroku Postgres.

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

Lonti does not charge an additional per-connector or per-vendor fee to integrate Heroku. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Heroku, Salesforce, cloud infrastructure, database services, or other third-party systems according to their subscriptions, usage, and deployment model.

Which Heroku integration methods should an enterprise use?

The Heroku Platform API is the primary method for resource synchronization and platform automation. App Webhooks are useful for selected lifecycle events, but they do not cover every Heroku resource or change. Scheduled REST polling is appropriate for reconciliation, and PostgreSQL connectivity is appropriate for Heroku Postgres application data. No official Heroku GraphQL or SOAP API was confirmed.

Are Heroku webhooks available for event-driven integrations?

Yes, Heroku App Webhooks support selected app lifecycle and platform events, including certain Build, Release, Dyno, Config Var, Domain, Collaborator, and Add-on changes. Coverage is selective, so integrations should verify the required event type and retain polling for unsupported or reconciliation scenarios.

How does synchronization with Heroku work?

A Martini workflow can poll the Platform API on a schedule, follow pagination links, store a checkpoint, compare stable identifiers or timestamps, and write idempotent updates to a target system. For supported webhooks, Martini can receive the notification, retrieve the current resource, and reconcile it before downstream processing.

How does Martini handle Heroku mapping, errors, and duplicate events?

Martini can map Heroku JSON or PostgreSQL rows into canonical and target models, apply validation and business rules, and route failures through workflow error handling. Stable event identifiers, resource IDs, timestamps, or checkpoints can prevent duplicate writes. Rate limits and transient failures should use bounded retries with backoff, while permanent validation or permission errors should be surfaced for review.

Related Martini documentation

APIs

Events

Workflows

Security

Operations

Integrate Heroku with Martini

Use Martini to orchestrate Heroku API access, selected webhook events, scheduled synchronization, and Heroku Postgres workflows across your enterprise systems.

EXPLORE MARTINI
BOOK A DEMO