.png)
Matillion Integration Guide
Integrate Matillion with enterprise systems through REST APIs that start, parameterize, and monitor data integration jobs.
Matillion integration options at a glance
Matillion’s primary integration mechanism for control-plane automation is its REST API, available across Matillion Data Productivity Cloud and Matillion ETL with product-specific authentication and resource models. Martini can discover Projects, Environments, Jobs, and execution information, start supported jobs, pass permitted parameters, and monitor asynchronous execution. General-purpose outbound callbacks for every job lifecycle event were not confirmed, so scheduled polling is the safer general pattern. Martini can also expose a controlled REST API for approved pipeline requests, while connecting separately to warehouses or databases when direct data access is required.
| Integration point | Supported by Matillion? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Discover Projects, Environments, and Jobs; start or stop supported jobs; pass permitted parameters; and retrieve execution information. | Martini can consume Matillion REST APIs, map requests and responses, and orchestrate the resulting operations in workflows. |
| Bulk and asynchronous job execution | Limited | Initiate Matillion data movement and transformation jobs and monitor their asynchronous execution. This is not a general-purpose bulk CRUD API. | Martini stores the returned execution identifier, polls status at controlled intervals, and applies success, timeout, and retry rules. |
| Webhooks and outbound callbacks | Not confirmed | A general-purpose callback API for all Matillion job lifecycle events was not confirmed. Product-specific callback features should be verified before use. | Martini can use scheduled workflows to poll execution status when callbacks are unavailable and can receive confirmed webhook-style inputs from other systems. |
| Authentication | Yes | Matillion API access uses product- and deployment-specific authentication, including Basic Authentication or token and bearer-token patterns. | Martini can externalize credentials and tokens through protected environment configuration and secrets rather than embedding them in workflows. |
| Database and analytics access | Limited | Matillion works with external warehouses and databases, but direct access to its control-plane database was not confirmed. | Martini can consume Matillion APIs for orchestration and connect separately to a supported warehouse or database when direct data access is needed. |
| File and attachment APIs | Not confirmed | Matillion supports file-oriented data workflows through data integration components, but a general Matillion attachment API was not confirmed. | Martini should not model file components as a Matillion attachment API and can instead integrate with the relevant storage or file endpoint separately. |
| GraphQL APIs | Not confirmed | No current Matillion GraphQL API was confirmed in the reviewed official documentation. | Martini should use the confirmed Matillion REST APIs rather than assume GraphQL support. |
| SOAP APIs | Not confirmed | No current Matillion SOAP API was confirmed in the reviewed official documentation. | Martini should use Matillion REST APIs for this integration rather than assume SOAP support. |
How Matillion exposes data and business events
Matillion REST APIs
Matillion Data Productivity Cloud and Matillion ETL expose REST APIs for product-specific resources and job or orchestration control. The available endpoints, authentication pattern, and resource model vary by product and deployment.
Martini implementation pattern
Martini implementation pattern: Martini authenticates against the selected Matillion API, retrieves or validates Projects, Environments, and Jobs, submits an approved operation, maps the response, and records correlation data for later monitoring.
Implementation sequence
Asynchronous job execution
Starting a Matillion Job commonly initiates asynchronous processing. The API response can provide execution or task information that must be followed through a status endpoint rather than treated as the final business result.
Martini implementation pattern
Martini implementation pattern: a workflow starts the Job, stores its execution identifier, waits between status requests, distinguishes running, successful, failed, cancelled, timed-out, and indeterminate outcomes, and routes the result to downstream systems.
Implementation sequence
Scheduled status polling
A universal outbound callback mechanism for Matillion job lifecycle events was not confirmed. Scheduled polling is therefore the safer general method for monitoring asynchronous executions when a specific callback feature is unavailable.
Martini implementation pattern
Martini implementation pattern: a scheduler-triggered workflow retrieves active executions, polls only those within their monitoring window, applies bounded backoff and timeout rules, and sends operational notifications when an execution completes or exceeds expectations.
Implementation sequence
Common Matillion integration patterns
Pattern 1: Start Matillion from a business-system event
When to use this pattern
Use this pattern when a Salesforce, HubSpot, ServiceNow, or other upstream event should initiate a Matillion pipeline. Martini validates the request, applies an allowlist, and returns an accepted response while the Matillion execution continues asynchronously.
Integration direction
Example Mapping
| Matillion Field | Canonical Field | Target Field |
|---|---|---|
| eventId | correlationId | requestCorrelationId |
| jobName | pipelineIdentifier | jobIdentifier |
| eventDate | processingDate | jobParameterDate |
Martini implementation pattern
Martini receives the event through an API, validates the business object and permitted Job, maps supported parameters, invokes Matillion REST APIs, and returns a tracking identifier. A separate workflow polls the execution and routes failures for operational handling; duplicate requests are checked using the correlation ID.
Martini capabilities used
- API consumption
- workflow orchestration
- data mapping
- business rules
- error handling
Pattern 2: Schedule and monitor a Matillion pipeline
When to use this pattern
Use this pattern when Martini must coordinate a recurring Matillion execution, check prerequisites, or centralize operational monitoring. It is useful when downstream notification or incident handling depends on the final Job result.
Integration direction
Example Mapping
| Matillion Field | Canonical Field | Target Field |
|---|---|---|
| scheduleTime | requestedRunTime | executionWindow |
| executionId | trackingId | correlation_id |
| status | pipelineStatus | incidentState |
Martini implementation pattern
A scheduler-triggered workflow checks prerequisites, starts the approved Matillion Job, stores the execution identifier, and polls with bounded intervals. Terminal failures, API outages, and timeouts are handled separately, with failed pipeline information mapped into ServiceNow incident data where required.
Martini capabilities used
- scheduler triggers
- workflow orchestration
- API consumption
- mapping and transformation
- retry and error handling
Pattern 3: Route Matillion completion to downstream applications
When to use this pattern
Use this pattern when a completed Matillion load or transformation should trigger an operational update, customer-data refresh, notification, or issue-management action.
Integration direction
Example Mapping
| Matillion Field | Canonical Field | Target Field |
|---|---|---|
| projectId | pipelineProject | customfield_pipelineProject |
| jobId | pipelineJob | summary |
| executionStatus | pipelineOutcome | issueStatus |
Martini implementation pattern
Martini retrieves the final execution state, enriches it with Project, Environment, and Job context, applies routing and severity rules, and calls the downstream API. It uses correlation and duplicate checks so repeated polling does not create repeated issues or notifications.
Martini capabilities used
- scheduled workflows
- API consumption
- data enrichment
- business rules
- idempotency and error handling
Pattern 4: Expose a controlled API for pipeline requests
When to use this pattern
Use this pattern when internal applications need to request approved Matillion pipelines without receiving Matillion credentials or direct access to administrative endpoints.
Integration direction
Example Mapping
| Matillion Field | Canonical Field | Target Field |
|---|---|---|
| pipeline | approvedJob | jobIdentifier |
| parameters | validatedParameters | jobParameters |
| requestId | correlationId | executionCorrelation |
Martini implementation pattern
Martini exposes a secured REST API, validates callers and request parameters, enforces an allowlist and concurrency policy, invokes Matillion, and returns a tracking identifier. A status endpoint can expose normalized execution information while hiding product-specific credentials and endpoint details.
Martini capabilities used
- API exposure
- authentication and authorization
- validation
- API consumption
- workflow orchestration
Applications commonly integrated with Matillion
Matillion commonly sits between operational applications, cloud data platforms, and analytical workflows. Martini can coordinate Matillion job execution with these systems without exposing Matillion credentials or administrative endpoints directly. Specific component availability should be verified for the selected Matillion edition.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Snowflake | Load operational data into Snowflake and coordinate warehouse-oriented transformation pipelines. | Snowflake → Matillion → Martini | Martini invokes approved Matillion Jobs through the REST API, polls the returned execution identifier, and sends completion or failure status to Snowflake-related operational processes. |
| Amazon Redshift | Populate Redshift data warehouses and coordinate scheduled ELT workloads. | Amazon Redshift → Matillion → Martini | A Martini workflow validates the requested environment and job, starts the Matillion execution, applies timeout and retry rules, and records the resulting status for operations. |
| Google BigQuery | Load and transform data for analytics and reporting in BigQuery. | Google BigQuery → Matillion → Martini | Martini receives a pipeline request or schedule, maps approved parameters to a Matillion REST request, and monitors execution before notifying downstream systems. |
| Databricks | Coordinate ingestion and transformation workflows supporting lakehouse processing. | Databricks → Matillion → Martini | Martini orchestrates Matillion job control through REST, correlates the execution with the originating request, and routes failures to an operational process. |
| Salesforce | Replicate Accounts, Contacts, Leads, and Opportunities into analytical platforms through Matillion pipelines. | Salesforce → Matillion → Martini | Martini can receive a Salesforce-driven request, validate the relevant business context, start the appropriate Matillion Job, and return an accepted response with a tracking identifier. |
| HubSpot | Centralize Contacts, Companies, Deals, and marketing data for analytics and reporting. | HubSpot → Matillion → Martini | A scheduled or API-triggered Martini workflow starts the Matillion refresh, polls execution status, and routes successful completion or failure notifications to the required application. |
| ServiceNow | Load incidents and operational data into analytical platforms and create operational follow-up when pipelines fail. | Matillion → Martini → ServiceNow | Martini polls Matillion execution status, maps failed jobs to ServiceNow incident fields, and creates or updates an incident according to correlation and deduplication rules. |
| Jira | Combine issue data with delivery analytics or create issues for failed production pipelines. | Matillion → Martini → Jira | Martini receives a failed execution outcome, applies routing and severity rules, and creates or updates a Jira issue with the Matillion project, job, and execution context. |
How to build a Matillion integration in Martini
Objective
Configure the Matillion product edition, base URL, API version, credentials, tokens, and permissions required by the integration.
Instructions in Martini
- Identify whether the target is Matillion Data Productivity Cloud or Matillion ETL
- Store tenant URLs, credentials, and tokens in protected environment configuration
- Grant only the permissions required to read resources and start or monitor approved Jobs
- Configure the REST API request with the product-specific authentication method
Objective
Select an event, API request, or schedule that should initiate Matillion control-plane activity.
Instructions in Martini
- Use an API-triggered workflow for business-system requests
- Use a scheduler trigger for recurring execution or polling
- Do not assume universal Matillion lifecycle callbacks
- Define correlation and deduplication behavior before submitting a Job
Objective
Resolve the relevant Project, Environment, Job, and request parameters before execution.
Instructions in Martini
- Retrieve resource lists with pagination where applicable
- Validate Project, Environment, and Job identifiers against an allowlist
- Reject unsupported, unsafe, or incomplete parameters
- Record the request context without logging secrets
Objective
Start the Matillion Job and coordinate its asynchronous lifecycle in a Martini workflow.
Instructions in Martini
- Submit the approved REST request
- Store the execution identifier and correlation ID
- Poll status at bounded intervals when callbacks are unavailable
- Distinguish Matillion job failure from API or network failure
Objective
Normalize Matillion responses and execution states for downstream applications and operational processes.
Instructions in Martini
- Map product-specific fields to an internal execution model
- Convert vendor states into accepted, running, succeeded, failed, cancelled, timed-out, or indeterminate outcomes
- Enrich results with Project, Environment, and Job context
- Apply business rules for notifications and incidents
Objective
Deliver normalized execution results or downstream data to the required application, database, or API.
Instructions in Martini
- Call the downstream REST API after the required terminal state
- Create or update operational incidents using correlation identifiers
- Connect separately to a supported warehouse or database if direct data access is required
- Prevent duplicate writes during polling retries
Common Matillion data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Projects | Logical containers for Matillion Jobs, Components, configurations, and related development assets. | Martini, operations platforms, deployment processes, and analytical environments | Martini retrieves Projects through REST endpoints, filters them by permitted scope, and uses identifiers to validate downstream job requests. |
| Jobs | Executable orchestration or transformation processes. | Martini, cloud warehouses, business applications, and operational systems | Martini validates an allowlisted Job, maps supported parameters, starts the Job, and correlates its execution with the originating request. |
| Environments | Runtime or deployment contexts containing execution and connection configuration. | Martini, cloud data platforms, deployment configuration, and operations tools | Martini resolves the correct Environment from environment-specific configuration and avoids hard-coding deployment-specific identifiers. |
| Components | Job-level processing steps that extract, load, transform, query, route, or otherwise process data. | Matillion Jobs, warehouses, storage services, and source applications | Martini generally controls Components indirectly through Jobs and monitors the resulting execution rather than treating Components as a separate control workflow. |
| Job executions | Runtime instances created when a Job is started, including status and operational information. | Martini, monitoring platforms, ServiceNow, Jira, and notification APIs | Martini stores execution identifiers, polls status, maps vendor states to workflow outcomes, and applies timeout, retry, and deduplication rules. |
| Schedules or triggers | Scheduling and invocation configuration associated with Jobs, depending on product edition. | Matillion, Martini Scheduler, operations platforms, and deployment processes | Martini can coordinate scheduled invocation where appropriate, but the exact object model and availability must be confirmed for the target edition. |
Authentication and security considerations
Product-specific authentication
Matillion authentication varies between Data Productivity Cloud and Matillion ETL and may use Basic Authentication, tokens, or bearer-token patterns. Confirm the target API version and deployment before implementation.
Least-privilege access
Use an identity with only the permissions required to read Projects, Environments, and Jobs, start approved Jobs, and read execution status.
Protect secrets
- Store credentials, tokens, tenant URLs, and environment values in protected Martini configuration or secrets.
- Do not place secrets in workflow source, Job parameters, logs, or error payloads.
- Use environment-specific values for development, test, and production.
Operational considerations for Matillion integrations
Polling and rate limits
Use bounded polling intervals, filtering, pagination, and backoff. Treat throttling separately from Matillion Job failure and stop polling after a defined timeout.
Idempotency
A timeout on a Job-start request does not prove that the Job was not started. Use correlation IDs, active-execution checks where available, and a request-deduplication policy.
Validation and schema changes
Allowlist Job identifiers and validate parameters before submission. Monitor response-shape and component changes, test in non-production environments, and avoid assumptions about optional fields.
Operational monitoring
Map execution states to accepted, running, succeeded, failed, cancelled, timed-out, and indeterminate outcomes. Record sufficient context for troubleshooting without exposing credentials.
Why use Martini instead of scripts or point-to-point integrations?
Reusable orchestration
Martini separates Matillion API control from business-system workflows, allowing teams to reuse authentication, validation, polling, mapping, and error-handling logic.
Controlled access
A Martini API can provide an allowlisted façade for pipeline requests so calling systems do not need direct Matillion credentials or administrative access.
Reliable coordination
Workflows can coordinate asynchronous Job execution with schedules, downstream APIs, databases, and operational systems while applying correlation, retry, timeout, and duplicate-handling rules.
Maintainable integration assets
Compared with isolated scripts or point-to-point integrations, Martini provides a consistent place to manage environment configuration, transformations, business rules, monitoring, and deployment changes.
Frequently asked questions
Matillion can be integrated primarily through its REST APIs. Enterprise systems can use Martini to discover Projects, Environments, and Jobs, start supported Jobs, pass permitted parameters, and monitor asynchronous Job executions. Matillion ETL and Data Productivity Cloud have different API and authentication models, so the target product edition must be confirmed.
Yes. Martini can integrate with Matillion by consuming its confirmed REST APIs, securely storing the required credentials or tokens, starting approved Jobs, polling execution status, and coordinating results with upstream and downstream systems.
No. A dedicated Matillion connector is not required. Martini can use Matillion’s native REST APIs and product-specific authentication methods, with workflows handling request validation, job invocation, asynchronous monitoring, mapping, and error handling.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Matillion. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from Matillion, cloud infrastructure, warehouses, or other third-party systems based on subscription, usage, and deployment model.
REST APIs are the primary confirmed method for control-plane integration with Matillion. They can support resource discovery, Job initiation, parameter submission where available, and execution monitoring. GraphQL and current SOAP APIs were not confirmed, and file or attachment APIs should not be assumed.
A general-purpose outbound webhook or callback API covering all Matillion job lifecycle events was not confirmed. Martini should use scheduled polling of execution status as the safer general pattern unless the specific Matillion edition documents a callback feature.
Martini normally synchronizes control information rather than directly copying Matillion data. It starts a Job, stores its execution identifier, polls status with bounded intervals, and maps the final outcome to downstream systems. Direct data access should use the underlying warehouse, database, storage service, or business application separately.
Martini can validate and transform Job parameters and normalize product-specific execution states. Workflows can distinguish authentication, authorization, throttling, network, timeout, and Matillion Job failures, then apply backoff and retry rules. Correlation IDs, active-execution checks, and deduplication policies help prevent duplicate starts or downstream writes.
Yes. Martini can expose a secured REST API that validates callers and allowlisted Job parameters, invokes Matillion without revealing Matillion credentials, returns a tracking identifier, and provides a controlled status response backed by Matillion execution information.
Related Martini documentation
Workflows
Coordinate Matillion with your enterprise systems
Use Martini to build controlled, observable workflows around Matillion REST APIs, from Job requests and asynchronous monitoring to downstream operational automation.