Skip to content

Integrating SailPoint with Anypoint Exchange

Anypoint Exchange is MuleSoft's central asset marketplace where teams store, discover, and reuse APIs, pre-built connectors, and integration templates. It speeds up development and maintains security standards by providing built-in documentation, API mocking, and enterprise-wide asset sharing. This document provides the instructions required to configure a new direct connection between SailPoint and Anypoint Exchange. For a reference to the terminology specific to SailPoint products, refer to Source and Connector Definitions.

Note

To view the latest features, enhancements, and fixes for all SaaS connectors, refer to the SaaS Release Notes page.

Supported Features

The Anypoint Exchange connector supports the following:

Account Management

  • Aggregate Users

Entitlement Management

  • Aggregate Role Groups
  • Aggregate Teams

Note

This connector is read-only. It supports account and entitlement aggregation for Quick Compliance. Provisioning, de-provisioning, and write operations are not supported in this release.

Important

Quick Compliance connectors have the following manual aggregation limits within a 24-hour period:

  • Organization Admins: Limited to 3 manual account or entitlement aggregations per day per source. This limit is cumulative across all admins in the organization.
  • Regular Users: Limited to 1 manual account or entitlement aggregation per day per source.

These limits ensure that individual compliance statuses are kept up to date while maintaining continuous compliance monitoring. If you need to run additional aggregations beyond these limits, contact SailPoint Support.

Prerequisites

Before configuring the Anypoint Exchange connector, ensure the following requirements are met:

  1. Sign in to Anypoint Platform with an account that has Organization Administrator rights. Administrator rights are required because scoped access (for example, Exchange Administrator/Contributor scopes) can only be assigned by an org admin of the root organization or business group.
  2. Go to Access Management > Connected Apps and select Create App.
  3. Enter a unique App Name, and select App acts on its own behalf (client credentials) as the app type.
  4. Select Add Scopes and assign the required Exchange scope(s) based on the intended use case.
  5. Select the business groups and environments the app should have access to, then select Add Scopes.
  6. Select Save to generate the connected app. Copy and securely store the Client ID and Client Secret - the Client Secret may not be retrievable after this step.
  7. Complete the OAuth 2.0 client credentials flow to obtain an access token:

POST https://anypoint.mulesoft.com/accounts/api/v2/oauth2/token
Content-Type: application/x-www-form-urlencoded

client_id=<CLIENT_ID>
client_secret=<CLIENT_SECRET>
grant_type=client_credentials
8. The response returns a bearer access_token - this is what the connector uses to call Exchange APIs. 9. Record the following values for connector configuration: - Base URL - Token URL (https://anypoint.mulesoft.com/accounts/api/v2/oauth2/token) - Client ID - Client Secret - Organization ID (required to scope calls to the correct business group)

Token Notes

Note

  • Access tokens issued via the client credentials grant are short-lived - valid for 60 minutes. Calling the token endpoint again before expiry issues a fresh 60-minute token.
  • There is no separate refresh token in this flow; the connector re-authenticates using the Client ID and Client Secret directly whenever a new access token is needed, rather than storing and rotating a refresh token.
  • The Client Secret has no expiration date by default, but an expiration date can be set by an org admin. If secret rotation is enforced, the connector's stored credential must be updated before the old secret expires, or authentication will begin failing.
  • Connected apps are configured at the root organization level by default, not at the business group (sub-organization) level. If the target Exchange assets live under a specific business group, the app's scopes must be explicitly extended to that business group and environment during setup - otherwise calls may return empty results rather than an error.

Required Permissions

Who Can Generate a Client ID/Secret

Any organization administrator of the root organization or business group in which the app resides can create and manage a connected app. The app is owned by the organization itself, not by the individual who created it - any admin with access to that root org or business group can subsequently manage or rotate its credentials.

How Permissions Affect Connector Access

Access is governed entirely by the scopes explicitly granted to the connected app, not by the rights of the person who created it:

  • Exchange Viewer scope - read-only access, suitable for data aggregation and reporting use cases.
  • Exchange Contributor scope - read/write access, suitable for provisioning or data modification use cases.
  • Exchange Administrator scope - full read/write/delete access, suitable for provisioning and de-provisioning use cases.

Key behaviors to account for:

  • If the app is scoped as Exchange Viewer only, any write or publish calls the connector attempts will return a 403 Forbidden, regardless of who created the app.
  • If the app's scopes are not extended to the relevant business group and environment, calls will silently return empty or partial results for assets in that scope rather than a clear authorization error.
  • Scope, business group, and environment are set independently at app-creation time. It is possible to have an "administrator-level" Exchange scope that still cannot see certain assets simply because the relevant environment was never selected during setup.

Note

The linked document is not maintained by SailPoint and is subject to change without notice.