MGWC key terms

An integration approach that organizes reusable APIs into three layers: system APIs that expose core systems, process APIs that combine and orchestrate data, and experience APIs tailored to a specific channel or consumer.

The lowest layer of API-led connectivity. It exposes a single backend system such as a database, ERP, or SaaS application, hiding protocol and data-store details from everything above it.

The middle layer of API-led connectivity. It orchestrates calls to one or more system APIs, applies business logic, aggregation, and routing, and returns a business-level result to experience APIs.

The top layer of API-led connectivity. It shapes data for a specific consumer experience such as a mobile app, partner portal, or web front end, often trimming or reformatting fields for that channel.

RESTful API Modeling Language, a YAML-based specification for describing API resources, methods, request and response bodies, and reusable traits and types. MuleSoft tooling uses it to generate scaffolding and documentation.

OpenAPI Specification, a widely adopted standard for describing REST APIs in JSON or YAML. MuleSoft's design tooling supports importing and exporting OAS alongside RAML.

A reusable RAML or OAS file that holds shared traits, resource types, data types, or examples. Fragments are referenced by multiple API specifications to keep definitions consistent and avoid duplication.

The Anypoint Platform component where APIs are registered, versioned, and governed. It applies policies, manages contracts with consumers, and controls access to API instances across environments.

A registered deployment of an API in API Manager, tied to a specific environment and implementation. Policies and consumer contracts are attached to the instance rather than to the design.

A rule enforced by the API gateway on requests or responses, such as rate limiting, authentication, or header injection. Policies can be applied at the API instance level and ordered in a sequence.

A policy that requires callers to present a valid client ID and secret registered as an application contract, rejecting unregistered consumers before the request reaches the implementation.

A named set of rate and concurrency limits in API Manager that consumer applications are assigned to, allowing different throughput ceilings for different partners on the same API instance.

A policy that caps how many requests a consumer may make in a time window, protecting backend systems from overload and enforcing fair use across clients.

A policy that smooths traffic by limiting requests per time window and delaying or rejecting excess calls, often used to spread bursts rather than block them outright.

A resilience pattern that stops sending requests to a failing dependency after a threshold of errors, failing fast until a recovery window passes and the dependency is retried.

An authorization framework in which a client obtains an access token from an authorization server and presents it to the API. MuleSoft supports token enforcement policies and token provider configurations.

An identity layer built on OAuth 2.0 that adds authentication and issues an ID token describing the signed-in user. It is commonly used for single sign-on and for securing APIs behind an identity provider.

A policy or flow step that verifies a JSON Web Token's signature, issuer, audience, and expiry before trusting its claims, so forged or expired tokens are rejected.

Security Assertion Markup Language, an XML-based standard for exchanging authentication and authorization assertions between an identity provider and a service provider, often used for enterprise single sign-on.

A Mule configuration element that reads encrypted values from a secure properties file at runtime, keeping credentials such as passwords and keys out of source control and plain configuration files.

Externalized YAML or properties files that supply environment-specific values to a Mule application, so the same deployable artifact can run in development, test, and production with different settings.

An isolated runtime context in Anypoint Platform, such as Design, Sandbox, or Production, with its own applications, API instances, and credentials. Environments separate promotion stages and access control.

The packaged Mule application, typically a JAR, built once and promoted across environments unchanged except for externalized configuration. This build-once principle is central to reliable promotion.

An automated sequence that builds, tests, and deploys a Mule application on each change, usually running unit and integration tests and promoting the same artifact through environments.

MuleSoft's testing framework for Mule applications. It lets you mock message processors and connectors, assert flow behavior, and run tests automatically as part of a build pipeline.

MuleSoft's hosted runtime platform for deploying Mule applications, offering managed workers, autoscaling, logging, and zero-downtime updates without operating your own servers.

The Anypoint Platform console for deploying and monitoring applications, viewing logs, managing workers, and applying alerts across cloud and on-premises runtimes.

An isolated runtime instance of a Mule application in CloudHub. Each worker has its own memory and JVM, and adding workers or worker size increases capacity.

A CloudHub capability that adds or removes workers automatically in response to CPU or memory thresholds, keeping throughput stable during demand spikes while controlling cost.

A configuration that links multiple Mule workers so they share state such as object stores and coordinate tasks, preventing duplicate processing and enabling high availability.

A persistent key-value store used by Mule applications to remember state across messages, such as watermarks or deduplication keys. It can be shared across clustered workers.

The property that repeating the same request produces the same result without duplicating side effects. Integrations achieve it by tracking a unique request key and skipping already-processed messages.

A Mule scope that re-executes its enclosed processors when they fail, using a configurable retry count and delay. It handles transient faults such as brief network outages.

An error handler in Mule that catches a matching error and lets the flow continue with the next processor, useful when a failure is non-critical and the response can still be completed.

An error handler that catches a matching error, runs its own processing, and then rethrows the error so upstream flows or the caller still see the failure.

A namespaced identifier in Mule, such as HTTP:NOT_FOUND or VALIDATION:INVALID_EMAIL, that classifies a fault so error handlers can match it and respond appropriately.

A unique identifier attached to a request and carried through every downstream call and log entry, making it possible to trace one transaction across services during troubleshooting.

MuleSoft's transformation language and engine for converting data between formats such as JSON, XML, CSV, and Java objects, with functions for mapping, filtering, grouping, and joining.

The Mule component that hosts DataWeave scripts. It defines input and output metadata and executes the transformation between the current payload and the desired structure.

A named schema in DataWeave that declares fields, types, and optionality for structured data, enabling validation, coercion, and clearer mapping code.

The basic unit of processing in a Mule application: a sequence of processors with a message source that receives events and processors that transform, route, or send data onward.

A reusable sequence of processors invoked synchronously from a flow reference. It has no message source and shares the caller's error handling context.

A Mule component that calls another flow or subflow from within a flow, passing the current message and returning its result. It is the standard way to compose reusable logic.

The inbound endpoint of a flow, such as an HTTP listener, JMS consumer, or scheduler, that creates a Mule event and starts processing when a trigger occurs.

A stored marker recording the last successfully processed record or timestamp, so a scheduled or polling integration resumes from that point instead of reprocessing everything.

Coordinating multiple service calls within one integration flow, sequencing or parallelizing them, combining their results, and handling partial failures to produce a single business outcome.

A Mule router that sends the same request to several routes concurrently and merges their responses into one message, reducing latency when calls are independent.

A Mule router that evaluates DataWeave conditions in order and routes the message down the first matching branch, providing conditional logic inside a flow.

The runtime layer that sits in front of an API implementation and enforces policies such as authentication, rate limiting, and logging before requests reach the backend.

A lightweight application that exposes an API through the gateway and forwards traffic to an existing implementation, letting you apply policies without changing the backend service.

A configured notification in Anypoint Platform triggered by conditions such as error rates, response times, or worker health, sent to email or other channels so operations can react quickly.

A catalog for publishing and discovering reusable assets such as APIs, connectors, templates, and fragments, so teams can share and reuse integration building blocks.