Ellipse Gradient for Header

Ansible Automation Platform Integration Guide

Connect Ansible Automation Platform with enterprise systems through Automation controller REST APIs, selected webhooks, and orchestrated asynchronous job workflows.

Ansible Automation Platform integration options at a glance

Ansible Automation Platform’s primary system-to-system boundary is the Automation controller REST API, which supports resource retrieval, Job Template launches, job status monitoring, output retrieval, and administration subject to RBAC. Selected Job Template webhook mechanisms support source-control events from providers such as GitHub and GitLab, while event-driven Ansible provides broader event-source and rulebook capabilities where deployed. Jobs are asynchronous, so integrations should store job identifiers and poll for terminal status. Martini can authenticate with controller tokens, expose controlled APIs, receive selected webhook requests, validate and map inputs, orchestrate workflows, and route execution results to enterprise applications.

Integration pointSupported by Ansible Automation Platform?Common use casesHow Martini supports it
REST APIsYesThe Automation controller API supports retrieving and managing Job Templates, Jobs, Workflow Job Templates, Inventories, Projects, Credentials, Organizations, Schedules, job events, and output. It is also used to launch permitted Job Templates.Martini can consume the controller REST API, map request and response data, orchestrate multi-step calls, and expose reusable APIs around approved automation operations.
Webhooks / outbound callbacksLimitedController webhook-style launch mechanisms support selected source-control integrations, including GitHub and GitLab, for configured Job Templates. Coverage is not universal for controller objects or state changes.Martini can expose an API endpoint to receive selected webhook requests, validate signatures or payload requirements where configured, enrich the event, and invoke the controller API.
Bulk / async / batch APIsLimitedJobs execute asynchronously and can target many hosts through Inventories and playbooks. Administrative synchronization generally requires paginated REST calls and repeated idempotent operations rather than a universal bulk CRUD API.Martini can store Job identifiers, poll controlled intervals, apply timeout and terminal-state rules, and process paginated resources or batched requests through workflows.
File / attachment APIsLimitedAutomation content is commonly sourced through Projects and source-control repositories, while job output and event data are available through APIs. A general business-attachment API should not be assumed.Martini can call documented content or project endpoints and process returned output, but should route arbitrary business files through an explicitly supported repository or file service.
Database / analytics accessLimitedOperational data should be consumed through documented APIs rather than direct access to the controller database. Analytics and reporting availability varies by deployment and version.Martini can consume documented reporting or analytics endpoints when available and can persist normalized results in an approved database without coupling to internal controller storage.
AuthenticationYesController integrations can use OAuth 2 access tokens or personal access tokens, with session and some Basic authentication configurations also available. RBAC controls access by users, teams, organizations, roles, and objects.Martini can store credentials securely, use token-based API authentication, trust required TLS certificates, and keep component-specific credentials separate.
Event-driven AnsibleLimitedEvent-driven Ansible can consume supported event sources, evaluate rulebooks, and invoke automation actions where the relevant component and configuration are deployed.Martini can provide or consume surrounding APIs and events, enrich event data, and coordinate downstream systems, while the exact event sources remain deployment-specific.

How Ansible Automation Platform exposes data and business events

Ansible Automation Platform REST APIs

Automation controller exposes REST endpoints for resource administration, Job Template launches, asynchronous Job monitoring, job events, output, Inventories, Projects, Credentials, Organizations, Schedules, and Workflow Job Templates. Exact paths and fields vary by platform version and deployed component.

Martini implementation pattern

Martini implementation pattern: Martini authenticates to the documented controller API, retrieves or validates the target resource, submits a permitted launch or update, stores correlation data, and transforms the response for the requesting or downstream system.

Implementation sequence

Authenticate with a component-appropriate controller token
Validate the requested resource and permitted operation
Retrieve required Inventory, Project, Credential, or Job Template details
Launch the Job Template or Workflow Job Template with constrained inputs
Store the returned Job identifier and correlation ID
Poll the Job until a terminal state or timeout is reached strain

Ansible Automation Platform webhooks

Controller supports webhook-style Job Template launches for selected source-control providers, including GitHub and GitLab. This is selected coverage rather than a universal outbound callback for every controller object or state transition.

Martini implementation pattern

Martini implementation pattern: Martini exposes an endpoint when it should mediate the event, validates the source payload and business conditions, enriches the event with approved context, and calls the controller REST API. Where the controller receives the webhook directly, Martini can process related downstream status and audit flows.

Implementation sequence

Receive the supported source-control webhook request
Validate the event type, repository, branch, and delivery identifier
Apply approval and duplicate-event rules
Map the event to an approved Job Template launch
Submit the launch request to the controller API
Persist the event and returned Job identifier

Asynchronous Ansible Jobs

Launching a Job Template normally returns a Job reference before playbook execution completes. Job status, output, events, timing, and terminal results are then available through controller API resources subject to permissions.

Martini implementation pattern

Martini implementation pattern: Martini models execution as a long-running workflow rather than treating a successful launch response as a successful automation result. It polls with controlled backoff, separates transport failures from playbook failures, and publishes normalized outcomes.

Implementation sequence

Receive the asynchronous Job reference
Schedule controlled status polling
Retrieve status and selected execution metadata
Retrieve job events or output when required
Apply success, failure, canceled, and timeout rules
Write the normalized result and preserve the controller Job ID

Common Ansible Automation Platform integration patterns

Pattern 1: Submit approved automation requests

When to use this pattern

Use this pattern when a service-management product, internal portal, or application needs to request a controlled infrastructure or remediation action. Martini provides the policy boundary so callers cannot freely select privileged templates, credentials, inventories, or variables.

Integration direction
ServiceNow
Martini
Ansible Automation Platform
Example Mapping
Ansible Automation Platform FieldCanonical FieldTarget Field
request.numbercorrelationIdextra_vars.request_id
requested_actionautomationActionJob Template identifier
environmentenvironmentextra_vars.environment
host_grouptargetGroupextra_vars.host_group
Martini implementation pattern

A Martini API receives the request, validates the action against an allowlist, checks approval and duplicate-request rules, maps permitted fields into launch-time extra variables, and calls the controller REST API. It stores the Job ID, polls for completion, and updates the originating request with a normalized result. Invalid input, authorization failures, transient API errors, and failed Jobs follow separate error paths.

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

Pattern 2: Enrich source-control events before automation

When to use this pattern

Use this pattern when GitHub or GitLab repository activity should trigger an Ansible Job Template but requires validation, release metadata, approval checks, or routing before execution.

Integration direction
GitHub
Martini
Ansible Automation Platform
Example Mapping
Ansible Automation Platform FieldCanonical FieldTarget Field
repository.full_namerepositoryextra_vars.repository
refsourceRevisionextra_vars.revision
sender.loginrequestedByextra_vars.requested_by
delivery_ideventIdextra_vars.event_id
Martini implementation pattern

Martini receives a supported webhook event or participates alongside the controller webhook, validates the repository and revision, rejects duplicate deliveries, enriches the request with release or business context, and launches an approved Job Template. The workflow records the event and Job identifiers and routes failed launches or failed automation to an operational queue.

Martini capabilities used
  • webhook consumption
  • API exposure
  • workflows
  • mapping
  • validation
  • retry and error handling

Pattern 3: Synchronize inventory data

When to use this pattern

Use this pattern when a CMDB, asset database, Red Hat Satellite, or cloud inventory is the system of record and Ansible Inventories must reflect approved hosts and groups.

Integration direction
Red Hat Satellite
Martini
Ansible Automation Platform
Example Mapping
Ansible Automation Platform FieldCanonical FieldTarget Field
host.namehostNameInventory host name
host.environmentenvironmentInventory variable
host.groupgroupNameInventory group
host.external_idsourceIdInventory variable
Martini implementation pattern

A scheduled Martini workflow retrieves source data, follows pagination, normalizes host and group identifiers, compares source and controller state, and applies only required idempotent updates. It throttles changes, records reconciliation results, and retries transient API failures without repeating completed updates.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • pagination orchestration
  • data mapping
  • business rules
  • idempotency
  • monitoring

Pattern 4: Distribute automation results

When to use this pattern

Use this pattern when Ansible executes the operation but a service-management, work-management, audit, or reporting platform owns the business record and needs reliable execution outcomes.

Integration direction
Ansible Automation Platform
Martini
Jira
Example Mapping
Ansible Automation Platform FieldCanonical FieldTarget Field
job.idexecutionIdJira automation reference
job.statusexecutionStatusJira status
job.failedfailureReasonJira description
job.finishedcompletedAtJira completion timestamp
Martini implementation pattern

Martini polls selected Jobs or receives a status request, retrieves permitted metadata and output, redacts sensitive values, maps terminal states to the target work item, and preserves the controller Job ID for audit. Large output is summarized or stored through an appropriate controlled destination, while timeouts and API failures are retried separately from playbook failures.

Martini capabilities used
  • workflows
  • REST API consumption
  • data transformation
  • redaction rules
  • error handling
  • monitoring

Applications commonly integrated with Ansible Automation Platform

Ansible Automation Platform commonly operates alongside source-control, service-management, cloud, virtualization, and infrastructure-management products. Martini can provide a controlled orchestration layer between these applications and the platform without implying a dedicated native connector.

Application Scenario Direction Martini Pattern
ServiceNow Create approved automation requests and update incidents, changes, configuration records, and audit records with execution status. ServiceNow → Martini → Ansible Automation Platform Expose a Martini API for approved requests, validate the requested Job Template and inputs, launch the controller job, poll its status, and write normalized results back to ServiceNow.
GitHub Use repository activity to trigger automation and provide source content for Ansible Projects. GitHub → Ansible Automation Platform Use a configured controller webhook for supported events, or receive and validate the event in Martini before enriching the payload and invoking the controller REST API.
GitLab Start automation from repository events and use GitLab repositories as sources for Projects. GitLab → Ansible Automation Platform Receive a selected GitLab event through a Martini endpoint or controller webhook, validate branch and project context, and launch an approved Job Template with controlled inputs.
Red Hat Satellite Coordinate host lifecycle, provisioning, patching, and configuration operations across Red Hat infrastructure. Red Hat Satellite → Martini → Ansible Automation Platform Retrieve approved host or lifecycle data, map it to Inventory or Job Template inputs, launch automation, and route job outcomes to operational records.
Amazon Web Services Automate cloud provisioning, configuration, inventory, and remediation operations through Ansible content. Martini → Ansible Automation Platform → Amazon Web Services Use Martini to validate the requested operation and environment, launch a permitted Job Template with constrained variables, and distribute the resulting status to the requesting system.
Microsoft Azure Automate Azure resource operations, configuration, and remediation using Ansible automation content. Martini → Ansible Automation Platform → Microsoft Azure Orchestrate an approved controller launch from Martini, enforce environment and resource rules, poll the Job, and normalize success or failure for downstream systems.
VMware vSphere Automate virtual machine provisioning, configuration, and lifecycle activities. Martini → Ansible Automation Platform → VMware vSphere Accept a validated infrastructure request, map it to a Job Template and Inventory, monitor asynchronous execution, and preserve the controller Job ID for audit.
Jira Track automation requests, remediation work, failures, and operational follow-up in work items. Jira → Martini → Ansible Automation Platform Use Martini to translate Jira requests into approved controller launches and to update Jira with terminal job states, selected output, and correlation identifiers.

How to build a Ansible Automation Platform integration in Martini

Objective

Establish a component-specific connection to Automation controller or another documented Ansible Automation Platform service.

Instructions in Martini

  • Confirm the deployed platform component, version, base URL, and API path.
  • Use HTTPS and a dedicated least-privilege service account.
  • Store controller tokens and certificates in protected Martini configuration or secrets management.
  • Configure the required REST API authentication and TLS trust.

Objective

Select the event, API request, or schedule that should start the integration workflow.

Instructions in Martini

  • Use a Martini API for approved automation requests.
  • Use a webhook endpoint for supported GitHub or GitLab event mediation.
  • Use a scheduler for inventory reconciliation or Job monitoring.
  • Document the specific event coverage rather than assuming universal callbacks.

Objective

Collect the controller resources and source-system data required for a safe operation.

Instructions in Martini

  • Retrieve Job Templates, Inventories, Projects, or other required resources through documented APIs.
  • Follow pagination and next-page information on list responses.
  • Capture source identifiers, correlation IDs, and controller Job IDs.
  • Check project synchronization or prerequisite status where relevant.

Objective

Coordinate validation, launch, asynchronous monitoring, and downstream routing in a maintainable Martini workflow.

Instructions in Martini

  • Validate the requested operation against approved templates, inventories, credentials, and environments.
  • Submit the Job Template or Workflow Job Template launch request.
  • Store the returned Job reference and schedule controlled polling.
  • Separate transport errors, validation errors, and playbook execution failures.

Objective

Convert source-system requests, controller responses, and job output into stable internal and target models.

Instructions in Martini

  • Map source fields to constrained launch-time extra variables.
  • Normalize controller status, timestamps, identifiers, and selected output.
  • Redact secrets and sensitive variables before logging or forwarding.
  • Preserve unknown fields where practical when passing version-sensitive data.

Objective

Enforce approval, authorization, idempotency, throttling, and operational policies before and during automation.

Instructions in Martini

  • Reject unapproved Job Template, Credential, Inventory, or destructive-action requests.
  • Use request identifiers and active-job checks to prevent duplicate launches.
  • Apply polling limits, concurrency controls, and backoff for transient failures.
  • Route failed, canceled, and timed-out Jobs to distinct operational handling.

Common Ansible Automation Platform data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
Job TemplatesReusable definitions containing playbooks, inventories, credentials, extra variables, and execution settings.ServiceNow, Jira, GitHub, GitLab, internal request portalsMartini retrieves approved templates, validates the selected identifier and permitted inputs, and launches them through the controller API.
JobsIndividual asynchronous executions with status, timing, output, events, and execution metadata.ServiceNow, Jira, monitoring platforms, audit storesMartini stores the Job ID, polls for terminal status, retrieves selected output, applies timeout and retry rules, and maps results to downstream objects.
Workflow Job TemplatesMulti-stage automation orchestration with success, failure, and always-run relationships between Job Templates.Change systems, request portals, operational dashboardsMartini submits validated workflow inputs, monitors the resulting execution, and routes outcomes according to business rules.
InventoriesCollections of hosts and groups targeted by automation runs.CMDBs, asset databases, Red Hat Satellite, cloud inventoriesMartini synchronizes approved host and group data through paginated, idempotent API operations or passes controlled selectors to Job Templates.
ProjectsSource-controlled collections of Ansible playbooks and related automation content.GitHub, GitLab, source-control repositories, release systemsMartini can coordinate project metadata or synchronization status through documented APIs and prevent launches when required content synchronization fails.
CredentialsStored authentication data used by jobs to access repositories, infrastructure, clouds, networks, and other services.Identity systems, cloud platforms, infrastructure platformsMartini references permitted credentials by identifier and avoids placing secrets in launch payloads, workflow definitions, logs, or error messages.

Authentication and security considerations

Component-specific authentication

Automation controller commonly supports OAuth 2 access tokens or personal access tokens for unattended integrations. Session authentication is more appropriate for interactive use, while Basic authentication may be available in some configurations. Other platform components can have separate endpoints and authentication requirements.

Least-privilege access

Use a dedicated integration identity with only the permissions required to launch approved Jobs, inspect status, read Inventories, or perform explicitly authorized updates. RBAC is governed through users, teams, organizations, roles, and object-level permissions.

Secrets and transport

  • Use HTTPS for all API calls and configure trust for private certificate authorities where required.
  • Store controller tokens and other secrets in protected Martini configuration or secrets management.
  • Do not place credentials in extra variables, logs, URLs, workflow definitions, or error messages.

Operational considerations for Ansible Automation Platform integrations

Asynchronous execution

A launch response identifies a Job but does not confirm successful playbook execution. Store the Job ID, poll with controlled intervals, apply a maximum timeout, and distinguish successful, failed, canceled, and error states.

Pagination and capacity

List endpoints can be paginated. Follow next-page information, use filtering where available, throttle reconciliation, and avoid excessive polling or duplicate launches that could increase controller and execution-node load.

Idempotency and input control

Use caller request IDs, active-Job checks, and explicit deduplication rules. Validate Job Template identifiers, Inventories, Credentials, environments, host selectors, and extra variables before launch, particularly for destructive operations.

Errors, versions, and testing

  • Separate authentication, authorization, validation, network, TLS, timeout, and playbook execution failures.
  • Use backoff for transient API failures and preserve controller Job IDs for support.
  • Use documented APIs rather than undocumented fields or direct database access.
  • Test mappings against the deployed platform version and verify Project synchronization and collection dependencies before production launches.

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

Centralized orchestration

Martini can coordinate enterprise requests, controller API calls, webhook handling, asynchronous polling, downstream updates, and operational notifications in one workflow rather than scattering logic across scripts.

Controlled integration boundary

A Martini API façade can expose business-level operations while keeping controller tokens, Job Template identifiers, credential references, and privileged launch rules behind a governed integration layer.

Maintainable transformation and policy

Reusable mappings, validation, business rules, retries, timeout handling, and error routes make integrations easier to change when source applications or Ansible platform versions evolve.

Operational visibility

Martini workflows can preserve correlation IDs and controller Job IDs, normalize execution outcomes, and route results to service-management, work-management, audit, or monitoring systems without treating an HTTP launch response as final success.

Frequently asked questions

How can Ansible Automation Platform be integrated with enterprise systems?

The primary approach is the Automation controller REST API, which supports resource retrieval, Job Template and Workflow Job Template launches, asynchronous Job monitoring, output retrieval, and selected administration. Selected GitHub and GitLab webhook scenarios and event-driven Ansible capabilities can support event-based automation where deployed. Enterprise systems can use Martini as an API, mapping, orchestration, and result-routing layer.

Can Martini integrate with Ansible Automation Platform?

Yes. Martini can consume the Automation controller REST API, authenticate with a permitted controller token, expose controlled APIs for automation requests, receive selected webhook events, launch Jobs, poll asynchronous execution, and map results to downstream systems. No native Martini Ansible Automation Platform connector is documented in the supplied context.

Do I need a connector to integrate Ansible Automation Platform with Martini?

No. A dedicated Ansible Automation Platform connector is not required. Martini can use the platform’s confirmed native REST APIs, selected webhook mechanisms, documented authentication methods, and asynchronous Job endpoints through workflows and APIs.

Is there any extra Lonti cost to integrate Ansible Automation Platform with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Ansible Automation Platform. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from Red Hat, cloud infrastructure, hosting, or other third-party systems depending on subscriptions, usage, and deployment model.

Which Ansible Automation Platform integration methods should be used?

Use the Automation controller REST API as the primary system-to-system interface. Use selected controller webhooks for supported source-control events, and use event-driven Ansible where the required event sources and components are deployed. GraphQL and SOAP interfaces were not confirmed, and direct controller database access is not the recommended integration boundary.

Can Ansible Automation Platform send events or webhooks to Martini?

Selected webhook and event-driven patterns are available, but there is no universal callback for every controller object or Job state. Controller Job Template webhooks are associated with supported source-control providers such as GitHub and GitLab. For general Job completion tracking, Martini can poll the controller REST API.

How does synchronization and Job monitoring work?

Martini can retrieve paginated resources, compare source and target state, apply idempotent updates, launch a Job, store its identifier, and poll until a terminal state or timeout. Successful launch of a Job does not mean the automation has completed, so transport status and playbook execution status should be handled separately.

Can Martini expose an API façade for Ansible Automation Platform?

Yes. Martini can expose a controlled REST API that accepts business-level requests, validates callers and allowed operations, maps inputs to approved Job Templates and extra variables, and returns or publishes normalized execution status. This façade can keep controller credentials and implementation details away from calling applications.