Why?

As telecom operators evolve toward more integrated IT and Network operations, a structural gap becomes evident.

Several CSPs are leveraging tools like n8n to automate administrative processes, accelerate internal workflows, and rapidly build MVPs for new services and operational models. These platforms provide agility and speed, particularly at the IT and business process layers.

However, when these workflows need to interact with the live network, a critical limitation emerges.

IT automation tools are not designed for carrier-grade, governed network execution. Extending them directly into the network domain often leads to one of two risky approaches:

• Direct integrations with network elements
• Unmanaged scripts operating outside a structured automation framework

Both introduce operational risk, reduce traceability, and compromise long-term architectural coherence.

True end-to-end automation in telecom environments requires a platform specifically designed for network-impacting execution  telco-native, multi-vendor, and governance-driven.

This is why we built the native n8n connector for MAT Framework.

It enables CSPs to preserve the agility of IT-driven workflows while delegating network-impacting actions to a governed, carrier-grade execution layer.

How It’s Used

The integration between n8n and MAT Framework is straightforward and production-ready.

A workflow is designed in n8n, typically combining business systems such as CRM, ITSM, Billing platforms, or internal approval processes. When the workflow reaches a step that requires network impact, the MAT Framework node is invoked.

The MAT node triggers a predefined, versioned, and governed automation inside MAT Framework. MAT executes the automation using its native orchestration engine, applying RBAC, CI/CD validation, maintenance window controls, and policy enforcement. Execution results are returned to n8n in a structured format, allowing the workflow to continue. 

MAT Framework provides two n8n nodes:

• MAT Framework Trigger
• MAT Framework Read

The Trigger node is used to execute Network Automations hosted in MAT Framework, while the Read node retrieves complete execution results. Both nodes can be found directly in the n8n node search panel.

MAT Framework Trigger

The MAT Framework Trigger node is used to execute automations developed in your MAT instance. To configure it, the following parameters are required:

Credential

The credential used to connect to MAT is generated from an API Key.

Step 1 – Generate the API Token in MAT

To create an API Token:

1. Log in to MAT Framework.
2. Click on your user profile.
3. Go to the API Tokens section.
4. Generate a new token with your desired administrative name.
5. Copy the generated token immediately.

Important: The token will not be visible again after this step. Make sure you copy and store it securely.

Step 2 – Configure the Credential in n8n

1. In n8n, double-click the MAT Framework Trigger node.
2. In the Credential selector, choose Create new credential.
3. Paste the API Token generated in MAT into the API Key field.
4. In Allowed HTTP Request Domains, select the appropriate option. 
5. Optionally, rename the credential by clicking on the name in the modal header and assigning your preferred administrative name.

Important Authentication Requirement

As with execution via MAT REST API, for the token to authenticate correctly and allow automation execution, the token must be configured inside the automation being executed in the target environment. Make sure the token is properly configured within the automation before attempting execution.

MAT REST API URL

This field corresponds to the MAT tenant URL you want to connect to from n8n. To obtain it:

1. In MAT Framework, click your user profile.
2. Go to REST API.
3. Inside the REST API portal, locate the Servers section.
4. Copy the domain listed there.
5. Paste it into the MAT REST API URL field in the n8n node.

Environment

Select the MAT environment where the automation will be executed. MAT Framework provides three isolated environments:

• Sandbox
• Pre-Production
• Production

If you are testing, we recommend selecting Sandbox.Note that if you choose Sandbox, the environment where the automation runs depends on which sandbox your MAT user is currently assigned to.

Also remember: the token must be configured in the automation within the specific environment where it will be executed.

Automation Type

Select the type of automation you want to execute:

• Network Task
• Network Workflow
• Orchestration Workflow

Execution Mode

The Execution Mode applies when the selected Automation Type is Network Task.

Network Tasks can run:

• Synchronously: the execution request waits until completion before returning a response.
• Asynchronously: the execution request immediately returns a Job ID.

In the case of Network Workflows and Orchestration Workflows, they always run asynchronously. In the case of Serverless Functions, always synchronously. 

Automation ID or Namespace ID + Function Name

For Network Task, Network Workflow, or Orchestration Workflow

You must provide the Automation ID of the automation to execute. To obtain it navigate to the automation in MAT Framework and copy its ID from the Dashboard.

Request Body

In this field, provide the input parameters required by the automation in JSON format (if applicable).

For Network Task, Network Workflow, or Orchestration Workflow, you must follow the correct structure including form_data. Parameter names must match those defined in the automation’s launch form. To find them:

1. Go to the automation in the Sandbox environment.
2. Open the automation configuration.
3. Select Edit Form.
4. Hover over the desired form field and click the gear icon.
5. In the API section, locate the property name.
6. Use that property name in the JSON request body.

Once these fields are completed, your MAT automation trigger is fully configured and ready to use.

Expected Outputs

The output depends on the automation type and execution mode.

1. Asynchronous Execution

For Network Tasks, Network Workflows and Orchestration Workflows executed asynchronously the expected output is the Job ID

2. Synchronous Execution – Network Task

The expected output includes the Job ID, Status = Finished and final state category corresponding to the job

Example:

3. Synchronous Execution – Serverless Function

The expected output includes the status and the data field with the output defined in the function’s return value

Example: