Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
Full Design Center entry
How-to guide

How to design an API in Design Center and publish it to Exchange

Design Center turns API design from a Word-document exercise into a versioned, validatable spec with a free mock endpoint. The path from blank canvas to published spec takes about 30 minutes for a small API.

By Dipojjal Chakrabarti · Founder & Editor, Salesforce DictionaryLast updated May 20, 2026

Design Center turns API design from a Word-document exercise into a versioned, validatable spec with a free mock endpoint. The path from blank canvas to published spec takes about 30 minutes for a small API.

  1. Open Design Center in Anypoint Platform

    Log into anypoint.mulesoft.com. From the home page, open Design Center. Click Create New, then API Specification.

  2. Choose the specification language

    Pick RAML 1.0, OAS 2.0, or OAS 3.0. OAS 3.0 is the current industry standard; RAML 1.0 is fine if your organization already standardizes on it.

  3. Author the API specification

    In the editor, define the API root (title, version, base URI), each endpoint, request and response schemas, and example payloads. The visual editor handles the YAML behind the scenes; advanced users can switch to direct YAML editing.

  4. Use the mocking service

    With the spec valid, the Mocking Service tab generates a public URL. Send sample requests; the mock returns the examples you defined. Share the mock URL with consumer teams for early integration testing.

  5. Publish to Exchange

    Click Publish to Exchange. Give the API a name, a description, and a version (1.0.0 for the initial release). The spec moves to Exchange where developers across your organization can discover and consume it.

  6. Iterate and version

    As you change the spec, publish new versions to Exchange. Anypoint Platform tracks every version and lets consumers stay on older versions while you ship newer ones. Document breaking changes in version notes.

Key options
OAS 3.0remember

Current OpenAPI standard. Use for new APIs unless your organization standardizes on RAML.

OAS 2.0 (Swagger)remember

Older but widely supported. Use when integrating with tools that have not adopted OAS 3.0 yet.

RAML 1.0remember

MuleSoft''s original specification language. Still common in MuleSoft-heavy organizations.

Flow Designer (Mule flows)remember

The no-code flow builder for simple integrations. Lives in Design Center alongside API Designer.

Gotchas
  • Mocking endpoints have no SLA and low rate limits. They are fine for design-time integration; do not use them for production traffic.
  • Publishing to Exchange creates a permanent record. Edits to a published version are limited; for substantive changes, publish a new version (1.1.0 or 2.0.0) and document the diff.
  • Flow Designer is not Anypoint Studio. The two share the runtime but have different feature sets. Complex Mule projects need Studio; Flow Designer is for simple, single-flow integrations.
  • API Fragments require Exchange permissions. Teams that want to reuse a Fragment need read access to the Exchange asset; without it, the import fails with a not-found error.

See the full Design Center entry

Design Center includes the definition, worked example, deep dive, related terms, and a quiz.