Boomi API Management cheat sheet

An API component in Boomi wraps a process or operation and exposes it through a shared API endpoint; the component holds the definition while the deployed API Service holds runtime configuration.

API Service deployment options: the shared Boomi Atom Cloud API gateway, a Private Atom Cloud API gateway, or a customer-hosted Atom/Molecule running the API Service capability.

API paths and operations are defined on the API component; HTTP methods, resource paths, and request/response profiles map to individual operations.

API authentication types include API key, OAuth 2.0 (client credentials, authorization code), Basic, and none; the choice is set per API, not per operation.

API policies run as ordered steps in a policy chain: request policies execute before the operation, response policies after, and fault policies on error.

The API gateway enforces rate limits, quotas, and caching at the gateway layer, so throttled requests never reach the backing process.

API versions are managed by publishing a new version of the API component; consumers bind to a specific version unless a versionless alias is used.

API metrics (calls, latency, errors, status codes) are captured by the gateway and surfaced in the API Management dashboards and monitoring logs.

A Developer Portal is configured per environment and publishes API documentation, credentials request flows, and consumer registration.

Governance operates at three layers: API component design standards, API Service deployment approval, and consumer access approval.

Role separation: API Manager creates and publishes APIs; Environment/Account Administrator controls deployment rights; custom roles can restrict who may publish to production.

Environments (Test, Stage, Prod) are separate API gateways; promoting an API means deploying the same API component version to the next environment.

Change control rule: a breaking change (removed operation, changed required parameter, changed auth type) requires a major version; additive changes may ship as a minor version.

Naming and metadata standards (owner, domain, lifecycle state, description) are enforced by review, not by the platform, so they belong in a documented API style guide.

Lifecycle states for an API are design, develop, test, publish, deprecate, retire; deprecation should precede retirement by a communicated notice period.

Audit trail: deployment and configuration changes are recorded in account audit logs; API call logs record consumer identity, path, status, and latency.

Consumer onboarding governance covers application registration, credential issuance, scope assignment, and periodic credential rotation.

API key authentication passes a key in a header or query parameter; it identifies the calling application but is not a user identity and must be paired with TLS.

OAuth 2.0 client credentials grant issues a token to an application without a user; authorization code grant issues a token on behalf of a user and requires a redirect URI.

Scopes restrict what a token may do; the gateway checks the token's scopes against the operation's required scopes before invoking the process.

JWT validation policies verify signature, issuer, audience, and expiry; an invalid or expired token returns 401 before any backend call.

Rate limit and quota policies protect backends from abuse: rate limit applies per time window, quota applies over a longer period, and both can key on consumer, IP, or API key.

Transport security: all API traffic should use HTTPS with TLS 1.2 or higher; mutual TLS can be required for partner or internal service-to-service APIs.

Payload protection policies can mask or reject sensitive fields; secrets should be stored in the platform's secure credential store, never in process properties in plain text.

Least privilege for gateway identities: the runtime service account should have only the permissions needed to deploy and run APIs in its environment.

An API Product bundles one or more API components with a shared plan, packaging them for a target audience such as internal teams or external partners.

A plan defines the access level for a product: rate limits, quotas, and which operations are exposed; multiple plans can exist for one product.

Consumers subscribe to a product plan through the Developer Portal; approval may be automatic or require a manual review step.

Product versioning follows the underlying API versions; adding an API to a product is additive, while removing one is a breaking change for subscribers.

A product's visibility setting controls whether it is public in the portal or restricted to selected consumer groups.

API keys and OAuth client credentials are issued per consumer application, not per product, so one application can subscribe to several products.

Subscription metrics (calls per consumer, errors per plan) drive plan tuning: raise limits on plans that hit quota, split noisy consumers into dedicated plans.

Retiring a product requires notifying subscribers, providing a migration path to a successor product, and revoking credentials after the notice period.