Ellipse Gradient for Header

Automox Integration Guide

Integrate Automox with enterprise systems through its REST API, selected notification mechanisms, and Martini workflows for endpoint, policy, and remediation orchestration.

Automox integration options at a glance

Automox provides a REST-oriented API for managing Organizations, Servers, Groups, Policies, Worklets, and Users. API-key authentication uses a bearer authorization pattern, with credentials stored securely in Martini. Automox also supports selected notification or integration scenarios, although event coverage should be confirmed for each required lifecycle event. Group-targeted and endpoint-management operations may support bulk or asynchronous behavior, which requires endpoint-specific verification and status handling. Martini can consume Automox JSON, paginate and reconcile resources, apply business rules, expose normalized APIs, and synchronize data with ITSM platforms, databases, reporting services, and notification tools.

Integration pointSupported by Automox?Common use casesHow Martini supports it
REST APIsYesRetrieve and manage Organizations, Servers, Groups, Policies, Worklets, and Users, and support endpoint-management workflows.Martini can consume the Automox REST API, process JSON responses, apply mappings and business rules, and expose downstream APIs.
Webhooks / outbound callbacksLimitedSelected notification or integration scenarios may provide operational event information, but coverage is not universal across Automox objects or lifecycle events.Martini can receive supported Automox webhook-style notifications and route them into workflows; unavailable events can be handled through scheduled polling.
Bulk / async / batch APIsLimitedAutomox manages endpoint populations and group-targeted operations, while the exact batch and asynchronous behavior must be verified for each endpoint.Martini can submit documented operations, persist correlation identifiers, poll status when available, and separate submission from completion handling.
AuthenticationYesAutomox API access primarily uses an API key sent with bearer authorization.Martini stores the API key as a secret and injects it into outbound requests without embedding it in workflow mappings or source files.
PaginationNot confirmedCollection endpoints may paginate results; the applicable page parameters and termination metadata should be confirmed in Automox documentation.Martini workflows can follow documented pagination, checkpoint progress, and restart failed synchronization pages safely.
File / attachment APIsNot confirmedNo general-purpose Automox file or attachment API was confirmed; Worklets should not be treated as a general file-transfer mechanism.Martini can exchange files through an explicitly supported external file service or object store and pass references through the integration.
Database / analytics accessNoNo direct customer database access was confirmed for Automox.Martini can persist API-derived Automox data in a supported SQL database for reporting, audit history, and reconciliation.
SDKsNot confirmedAutomox publishes API documentation and examples, but a dedicated Automox SDK was not verified.Martini can call the HTTP API directly without requiring an Automox-specific SDK.

How Automox exposes data and business events

Automox REST APIs

The Automox REST API is the primary programmatic integration method for Organizations, Servers, Groups, Policies, Worklets, and Users. It supports workflows that retrieve platform data, submit documented operations, and synchronize endpoint-management information with enterprise systems.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates with an API key stored as a secret, calls the appropriate Automox endpoint, handles pagination and response validation, maps JSON into a canonical model, applies business rules, and writes to the target system or exposes the result through a Martini API.

Implementation sequence

Load the organization and API configuration
Retrieve the Automox resource or operation response
Follow documented pagination until the collection is complete
Map Automox JSON into the target model
Apply authorization, filtering, and reconciliation rules
Write the result and persist source identifiers

Automox Notifications

Automox supports selected notification or integration scenarios, but it should not be treated as a universal event stream for every object or lifecycle event. Required device, policy, patch, or Worklet events must be confirmed for the customer configuration and plan.

Martini implementation pattern

Martini implementation pattern: expose a controlled receiving endpoint or use the supported Automox integration mechanism, validate the incoming notification, retrieve current Automox details when the payload is incomplete, and process the event idempotently. If the event is unavailable, use scheduled REST polling and reconciliation instead.

Implementation sequence

Confirm that the required Automox event is available
Receive the notification through the supported integration mechanism
Validate the organization and source identifiers
Retrieve current Automox details when necessary
Apply idempotency and business rules
Write the downstream result and record delivery status

Automox Bulk and Asynchronous Operations

Automox manages endpoint populations and supports group-targeted operational behavior, but exact batch capability and asynchronous status handling must be verified for each API operation. A successful submission does not necessarily mean that endpoint work has completed.

Martini implementation pattern

Martini implementation pattern: validate the requested scope, submit the documented operation, persist the response and correlation identifier, and poll a documented status resource when available. The workflow separates submission, completion, timeout, and failure states so downstream systems receive an accurate outcome.

Implementation sequence

Validate the requested Server or Group scope
Confirm authorization for the requested operation
Submit the documented Automox operation
Persist the returned request or operation identifier
Poll the documented status resource when available
Update the originating system with completion or timeout status

Common Automox integration patterns

Pattern 1: Synchronize Automox endpoints to a CMDB

When to use this pattern

Use this pattern when an enterprise needs a current inventory of Automox Servers, their Groups, and relevant Policy relationships in a CMDB or IT operations platform. It is appropriate for scheduled reconciliation where notification coverage is incomplete.

Integration direction
Automox
Martini
CMDB
Example Mapping
Automox FieldCanonical FieldTarget Field
Server.idendpoint.externalIdConfiguration item external ID
Server.nameendpoint.nameConfiguration item name
Server.osendpoint.operatingSystemOperating system
Group.idendpoint.groupIdsGroup references
Martini implementation pattern

A scheduled Martini workflow retrieves scoped Servers and related Groups, follows documented pagination, maps stable identifiers, and upserts CMDB items. It applies ownership and inactive-device rules, checkpoints progress, retries transient failures, and records the last successful synchronization timestamp.

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

Pattern 2: Create ServiceNow incidents from Automox failures

When to use this pattern

Use this pattern when patch failures, Policy failures, or remediation results must become actionable ServiceNow incidents. It supports both scheduled discovery and selected Automox notification scenarios.

Integration direction
Automox
Martini
ServiceNow
Example Mapping
Automox FieldCanonical FieldTarget Field
Server.nameaffectedEndpointConfiguration item
Policy.namecontrolNameShort description context
execution.failureReasonfailureReasonDescription
Automox organization/server/execution IDscorrelationKeyCorrelation field
Martini implementation pattern

Martini receives a supported notification or retrieves failure details through the REST API, enriches the event with Server and Policy data, and derives a deterministic correlation key. It creates or updates the ServiceNow incident, retries transient API failures, and stores both platform identifiers for reconciliation.

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

Pattern 3: Publish Automox compliance reporting

When to use this pattern

Use this pattern when security or operations teams need normalized reports on missing patches, Policy execution failures, Worklet results, or compliance trends by Organization and Group.

Integration direction
Automox
Martini
SQL database
Example Mapping
Automox FieldCanonical FieldTarget Field
Organization.idorganizationIdorganization_id
Server.idendpointIdendpoint_id
Policy.idpolicyIdpolicy_id
execution.statusexecutionStatusexecution_status
Martini implementation pattern

A scheduled workflow retrieves Automox Policies, Servers, Groups, and documented execution details, transforms the source payloads into reporting tables, and writes them to a SQL database. Martini preserves raw identifiers and timestamps, handles partial page failures, and can expose the normalized results through a separate API.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • JSON handling
  • data mapping
  • SQL persistence
  • API exposure
  • monitoring

Pattern 4: Orchestrate an Automox Worklet request

When to use this pattern

Use this pattern when an approved request, ticket, or operational workflow must initiate a documented Automox Worklet or endpoint operation. It is designed for privileged actions that may complete asynchronously.

Integration direction
ServiceNow
Martini
Automox
Example Mapping
Automox FieldCanonical FieldTarget Field
requester.idapprovedRequesterAutomox audit context
target.serverIdendpointIdAutomox Server identifier
target.groupIdendpointGroupIdAutomox Group identifier
request.reasonoperationReasonOperation metadata
Martini implementation pattern

Martini validates the request and authorization, confirms the target Server or Group, submits the documented Automox operation, and records the returned identifier. It polls or receives completion information where available, prevents duplicate submissions, and updates the originating request with success, failure, or timeout status.

Martini capabilities used
  • API workflows
  • authorization checks
  • data validation
  • business rules
  • asynchronous orchestration
  • idempotency
  • retry handling

Applications commonly integrated with Automox

Automox data and endpoint operations can be incorporated into broader IT operations, security, reporting, and notification workflows. The following are practical enterprise architecture patterns; any packaged capability or event coverage should be verified with the relevant product documentation.

Application Scenario Direction Martini Pattern
ServiceNow Create or update incidents and change records for patch failures, endpoint issues, and remediation activity. Automox → Martini → ServiceNow A scheduled Martini workflow or supported Automox notification retrieves the relevant Server, Policy, and execution details, derives a deterministic correlation key, maps severity and failure information, and creates or updates the ServiceNow record. Retry transient failures and persist both system identifiers for reconciliation.
Jira Create engineering or IT tickets for failed Policies, Worklet results, and endpoint compliance exceptions. Automox → Martini → Jira Martini polls Automox resources or processes a selected notification, normalizes endpoint and execution data, applies ticket-creation rules, and calls Jira APIs. Idempotency keys prevent duplicate issues when a failure is observed on multiple synchronization runs.
Splunk Send endpoint, patch, policy, and remediation information to centralized security and operations analytics. Automox → Martini → Splunk Martini retrieves or receives Automox data, transforms the JSON into an analytics event model, enriches it with organization and group context, and forwards it to Splunk using a supported HTTP ingestion endpoint. Failed deliveries are retried and retained for replay.
PagerDuty Trigger operational alerts for critical patching, policy, or endpoint-management failures. Automox → Martini → PagerDuty A Martini workflow evaluates Automox failure severity and deduplication fields, then creates, updates, or resolves PagerDuty incidents through its API. Business rules can suppress repeated notifications while preserving the underlying Automox execution history.
Slack Notify operations teams about remediation failures, compliance changes, or completed Worklet actions. Automox → Martini → Slack Martini maps selected Automox events or scheduled compliance results into concise Slack messages, routes them by organization or group, and records delivery outcomes. Notification failures are separated from Automox processing so they do not incorrectly mark the source synchronization as complete.
Microsoft Teams Deliver endpoint-management notifications to operations and security channels. Automox → Martini → Microsoft Teams Martini retrieves Automox status data or handles supported notifications, applies channel-routing rules, and posts formatted messages through the Microsoft Teams integration endpoint. Reconciliation can resend failed notifications without repeating endpoint actions.
Microsoft Intune Reconcile endpoint inventories or coordinate device-management responsibilities between overlapping endpoint platforms. Automox → Martini → Microsoft Intune Martini compares Automox Servers and Groups with Intune device data using stable identifiers where available, applies explicit ownership and conflict rules, and writes only approved changes. Because the platforms overlap, the workflow should define authoritative fields and avoid uncontrolled bidirectional updates.
Okta Use identity or group context to support access control, approvals, and administrative workflows around endpoint operations. Okta → Martini → Automox Martini receives an approved request or identity context from Okta-related workflows, validates the requester and target scope, and invokes the documented Automox operation with the stored API key. Authorization checks and audit records are required before privileged actions.

How to build a Automox integration in Martini

Objective

Establish the Automox API connection using the correct hostname, organization context, and an API key managed outside workflow logic.

Instructions in Martini

  • Confirm the Automox API hostname and organization scope
  • Store the API key in Martini Secrets Management
  • Configure bearer authorization for outbound REST requests
  • Use separate configuration for development, test, and production

Objective

Select an event-driven or scheduled trigger based on the required Automox event coverage and synchronization objective.

Instructions in Martini

  • Verify whether Automox provides the required notification event
  • Use a Martini receiving endpoint for supported notifications
  • Use a scheduler for inventory, compliance, or reconciliation workflows
  • Prevent overlapping large synchronization runs

Objective

Retrieve the current Automox resource state and account for collection pagination, scoped queries, and operation status.

Instructions in Martini

  • Retrieve Organizations, Servers, Groups, Policies, Worklets, or Users as required
  • Follow documented page and limit parameters
  • Persist checkpoints for restartable synchronization
  • Capture operation identifiers for potentially asynchronous actions

Objective

Coordinate source retrieval, enrichment, business rules, target calls, and completion handling in a maintainable Martini workflow.

Instructions in Martini

  • Separate event receipt or operation submission from completion processing
  • Retrieve related Server, Group, and Policy details when required
  • Route records by Organization, Group, severity, or target application
  • Define timeout and reconciliation behavior

Objective

Convert Automox JSON into canonical and target-specific models while preserving identifiers needed for traceability.

Instructions in Martini

  • Map stable Automox identifiers rather than display names alone
  • Normalize endpoint, policy, group, and execution fields
  • Preserve source timestamps and correlation identifiers
  • Validate required fields before sending target updates

Objective

Apply authorization, filtering, deduplication, scope, and ownership rules before creating records or initiating endpoint actions.

Instructions in Martini

  • Authorize privileged Server, Group, Policy, and Worklet operations
  • Derive deterministic keys for incident and notification creation
  • Avoid repeating an operation that is already in progress
  • Redact sensitive device or user data from logs where required

Common Automox data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
OrganizationsTop-level customer or tenant containers used to scope endpoint-management data and permissions.ServiceNow, CMDBs, SQL databases, reporting APIsMartini uses organization identifiers as configuration and correlation values, keeps them outside workflow logic, and applies organization-specific routing and authorization rules.
ServersManaged endpoint devices used for inventory, compliance, patching, and remediation workflows.CMDBs, ServiceNow, Splunk, Microsoft IntuneMartini retrieves paginated collections, maps stable identifiers and device attributes, performs upserts, and marks missing devices inactive during reconciliation.
GroupsLogical collections of managed devices used for organization, targeting, and policy assignment.CMDBs, reporting databases, Microsoft IntuneMartini preserves group relationships where the target supports them and uses group scope to route notifications or authorize endpoint operations.
PoliciesRules and schedules that define patching or remediation behavior for managed devices.ServiceNow, Jira, Splunk, reporting databasesMartini maps policy identifiers, schedules, assignments, and execution outcomes into compliance and incident models while retaining source identifiers for traceability.
WorkletsCustom scripts or automation packages used to inspect, configure, or remediate endpoints.ServiceNow, Jira, Slack, Microsoft TeamsMartini can validate an authorized request, invoke a documented Worklet operation, store the operation identifier, and poll or process completion information where Automox exposes it.
UsersAutomox administrative or platform users associated with an Organization.Identity workflows, audit databases, reporting systemsMartini can synchronize user identifiers and organization context while applying least-privilege and redaction rules to logs and downstream payloads.

Authentication and security considerations

API-key authentication

Automox API access primarily uses an API key sent with bearer authorization. Confirm the current header format, API hostname, organization context, permissions, and any regional requirements in the Automox documentation.

Secret protection

  • Store the Automox API key in Martini Secrets Management.
  • Do not embed credentials in workflow mappings, source files, URLs, logs, or error messages.
  • Use least-privilege permissions and rotate long-lived API keys according to organizational policy.
  • Use separate credentials and configuration for development, test, and production.

Privileged operations

Restrict any Martini API or workflow that can target Servers, Groups, Policies, or Worklets. Validate requester authorization and target scope before submitting endpoint operations, and retain audit information without exposing unnecessary device or user data.

Operational considerations for Automox integrations

Rate limits and pagination

Confirm Automox quotas and collection pagination in the current API documentation. Handle HTTP 429 and transient 5xx responses with bounded exponential backoff, avoid unnecessary per-endpoint polling, and checkpoint large synchronizations.

Idempotency and asynchronous work

Use stable Automox identifiers and deterministic correlation keys for upserts and ticket creation. Treat endpoint and Worklet operations as potentially asynchronous: persist returned identifiers, poll a documented status resource when available, and define timeout behavior.

Schema and configuration changes

Keep the Automox API version, base URL, organization identifiers, and environment-specific values configurable. Preserve unknown source fields where auditability matters, validate required fields, and monitor Automox documentation for resource and response changes.

Retries and reconciliation

Separate authentication, authorization, validation, throttling, transient, and endpoint-operation failures. Use scheduled reconciliation to recover from missed notifications or partial batch failures, and ensure retries cannot submit the same endpoint action repeatedly.

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

More than a one-off script

Martini provides a maintainable workflow layer around the Automox REST API. It can coordinate retrieval, enrichment, transformation, target-system updates, asynchronous operation handling, and reconciliation without duplicating this logic across point-to-point scripts.

Controlled integration APIs

Martini can expose normalized APIs for Automox inventory, compliance, or remediation data. This lets downstream systems consume a stable contract while Automox-specific authentication, pagination, identifiers, and endpoint behavior remain centralized.

Operational reliability

  • Use scheduled and event-driven workflows according to confirmed Automox coverage.
  • Centralize mappings, business rules, secrets, retries, and idempotency controls.
  • Persist checkpoints, correlation identifiers, and audit data for troubleshooting.
  • Reuse integration assets across ServiceNow, databases, reporting systems, and notification platforms.

Frequently asked questions

How can Automox be integrated with enterprise systems?

Automox can be integrated primarily through its REST API, which manages Organizations, Servers, Groups, Policies, Worklets, and Users. Selected notification or integration scenarios may support event-driven processing, while scheduled REST polling can provide reconciliation when a required event is unavailable.

Can Martini integrate with Automox?

Yes. Martini can consume the Automox REST API using an API key stored in secure configuration, transform Automox JSON, orchestrate endpoint and reporting workflows, expose normalized APIs, and receive supported Automox webhook-style notifications where available.

Do I need a connector to integrate Automox with Martini?

No dedicated Automox connector is required. Martini can integrate with Automox using its confirmed native REST API, bearer API-key authentication, selected notification mechanisms, and scheduled workflows.

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

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

Which Automox integration method should an enterprise use?

The Automox REST API is the primary method for current integrations and supports platform resources and operations. Selected notification mechanisms can be used for event-driven processing, while scheduled API synchronization is the fallback for events that Automox does not expose or that require periodic reconciliation.

Does Automox provide webhooks or events for every change?

No universal event stream should be assumed. Automox supports selected notification or integration scenarios, but coverage, callback behavior, payloads, retries, and subscription configuration must be verified for the specific device, Policy, patch, or Worklet event.

How does Martini synchronize Automox data?

Martini workflows retrieve Automox collections, follow documented pagination, map stable resource identifiers, and upsert data into CMDBs, ITSM platforms, databases, reporting APIs, or notification services. Checkpoints, retries, and scheduled reconciliation help recover from missed notifications or partial failures.

Can Martini expose an API façade for Automox data or operations?

Yes. Martini can expose a controlled API that normalizes Automox endpoint, Policy, compliance, or remediation information for downstream consumers. For privileged operations, the façade should enforce authorization, validate target scope, protect the Automox API key, and record an audit trail.

Related Martini documentation

Automox APIs

Workflows

Data

Security

Operations

Plan your Automox integration with Martini

Use Martini to connect Automox endpoint-management data and operations with enterprise workflows, APIs, databases, ITSM platforms, and reporting systems.

EXPLORE MARTINI
BOOK A DEMO