Salesforce MuleSoft Developer key terms

RESTful API Modeling Language: a YAML-based, human-readable syntax for describing an API's resources, methods, parameters, request bodies and responses. Anypoint Platform's designers use it to create and publish API specifications.

A widely used, language-agnostic standard written in JSON or YAML for describing REST APIs. Anypoint Platform can import OAS documents, generate flows from them, and publish them to Exchange.

A machine-readable contract describing an API's endpoints, operations, data types and error responses. It drives mocking, flow generation, request validation and documentation before any implementation logic exists.

A reusable RAML fragment that applies a set of method-level properties, such as headers or query parameters, to several resources at once. Traits keep specifications short by avoiding repeated declarations.

A RAML fragment defining a reusable template for a resource: its methods, descriptions and expected responses. Applied with the type keyword, it standardizes how similar resources are described across an API.

A hosted, simulated version of an API generated from its specification. It lets consumers send real requests and see example responses before the actual implementation is built or deployed.

A catalog where an organization publishes and discovers reusable assets such as API specifications, connectors, templates, examples and policies. It provides documentation, mocking and access requests for those assets.

A web-based editor in Anypoint Platform for writing and validating RAML or OpenAPI specifications. It offers suggestions, a built-in mocking service, and can publish the finished specification straight to Exchange.

The API Manager record that represents a deployed implementation of an API, identified through autodiscovery. Policies, SLA tiers and alerts are configured on the instance rather than in the application code.

The Anypoint Platform section for governing APIs: registering instances, applying policies, defining SLA tiers and checking analytics. Enforcement happens at the API gateway layer, outside the Mule flow itself.

A setting that links a running Mule application to a specific API instance in API Manager, usually through an API ID and the main flow name. The link is what allows gateway policies to be enforced.

MuleSoft's fully managed, hosted runtime plane where Mule applications run in the cloud. Deployments, worker sizes, regions and logs are configured through Runtime Manager.

The Anypoint Platform console for deploying, starting, stopping, scaling and monitoring Mule applications across CloudHub, customer-hosted servers and Runtime Fabric. It also exposes logs, alerts and application properties.

An API Manager policy that requires callers to send a client ID and secret issued to an application registered in Exchange. It authenticates consuming applications and supports contractual rate limits.

A named set of request limits, such as gold, silver or bronze, defined on an API instance. Client applications are assigned to a tier when they request access, and policies enforce those limits.

An API Manager policy that caps how many requests a client may send within a time window and rejects the excess with HTTP 429. It shields backend systems from overload and abusive traffic.

The basic unit of processing in a Mule application: an ordered sequence of message processors that receives, transforms, routes and responds to an event. A flow may have one message source and its own error handling.

A message source that opens an HTTP endpoint and starts a flow whenever a request arrives at its path. It returns the resulting payload to the caller as the response.

A connector operation that makes an outbound HTTP call from a flow to an external service and puts the response into the event. It supports headers, query parameters, authentication and error handling.

A generated message processor that matches incoming requests to flows based on the API specification. It validates the path, method, query parameters and body against the contract before the flow logic runs.

A reusable block of processing with no message source that is invoked only through a flow reference. It cannot declare its own error handler, so errors propagate back to the calling flow.

A configuration declared once at application level, such as an HTTP listener config, database connection or property placeholder, and reused by many components. It centralizes shared settings and credentials.

The unit of data travelling through a flow, made up of a message (payload plus attributes) and a set of variables. Each message processor reads and possibly changes it.

A variable segment of a request path, declared in the specification with braces, such as /orders/{orderId}. In a flow it is read from attributes.uriParams and used to look up the right record.

MuleSoft's functional language and engine for transforming data between formats such as JSON, XML, CSV and Java objects. It selects, maps and reshapes fields inside the Transform Message component.

The Mule component that runs a DataWeave script. It takes the current event as input and writes its result to the payload or to a variable named in the output directive.

A DataWeave header statement declaring the MIME type and structure of the produced data, for example output application/json. It tells the engine how to serialize the script's result.

The body of the Mule message: the actual business data being carried through the flow. DataWeave scripts refer to it with the payload keyword, which is the implicit root of the script.

Metadata about the message rather than its content, such as HTTP headers, query parameters, URI parameters and status codes. DataWeave reads them with the attributes keyword.

A DataWeave function that applies an expression to every element of an array and returns a new array of the same length. Inside the expression, $ is the current element and $$ its index.

A DataWeave function that walks the key-value pairs of an object and returns a new object. Inside it, $ is the value, $$ the key and $$$ the index.

A DataWeave function that collapses an array into a single value by applying an expression to each element together with an accumulator, starting from a supplied initial value.

A routing component that evaluates DataWeave conditions in order and sends the event down the first route whose condition is true, with an optional default route when none match.

A router that sends the same event to several routes in parallel and merges their outputs into an array of payloads. It shortens response time when the downstream calls are independent.

An error handler scope that runs its processors and then rethrows the original error to the caller, rolling back the current transaction. Use it when a failure must not be hidden or converted to success.

An error handler scope that runs its processors and returns their result as the flow's outcome instead of throwing. Use it when the application can recover and reply with a meaningful fallback.

A hierarchical identifier describing what went wrong, such as HTTP:NOT_FOUND or VALIDATION:INVALID_BOOLEAN. Error handlers match on error types to decide which handling strategy applies to a failure.

An error-handling configuration declared once at application level and referenced by several flows, so common failure logic is written in one place instead of repeated everywhere.

A Mule component that throws a custom error with a chosen error type from inside a flow. It lets developers signal business rule violations that error handlers can catch and format.