Modeling & Reuse

Service registry upgrades

Import OpenAPI, send multipart, authenticate flexibly, and pass on the caller's identity.

DesignPlatformWork

What it is

The service registry gains a broad set of upgrades that make integrating with external systems faster to model and safer to run. You can generate a service straight from an OpenAPI 3.1 specification, send richer request bodies including multipart uploads, choose how each operation authenticates, and carry the authenticated user’s identity through to the API being called.

Together these changes mean fewer hand-built integrations and a tighter fit with the way real APIs expect to be called, whether that is a file upload, a form-encoded body, or a call that must run as the end user rather than a service account. You can also mock a service’s responses with no code, so models that call it can be tested without the real service being available.

What’s included:

  • OpenAPI 3.1 import with the Service generator to scaffold a service from a specification.
  • Sending REST operations as multipart/form-data with a new Content Item parameter type and an optional per-part MIME type override.
  • Encoding request bodies as application/x-www-form-urlencoded.
  • Authenticating REST operations with an API key header or a custom-named header, matching the MCP service options.
  • Marking output parameters on Service Registry and Agent tasks as transient, so values are usable within the execution step but never persisted as variables or recorded in history.
  • Propagating the authenticated user’s identity to external APIs with On-Behalf-Of (OBO) OAuth 2.0 / OIDC token exchange on client registrations.
  • Specifying an audience parameter on OAuth2 client credentials token requests.
  • Code-free REST mocking: define a mock response (status code, body, headers, priority, match condition, sampling rate), toggle it per service or globally from Inspect in Flowable Work, with mocked executions clearly badged.

Mocking service responses

You can mock a registered REST service with no custom code, so a model that calls it can be tested without the real service being available. A mock response defines its status code, body, headers, priority, match condition and sampling rate. Mocking is toggled per service or globally from Inspect in Flowable Work, and any execution served by a mock is clearly badged, so a mocked result is never mistaken for a live call.

Defining a mock response: status code, body, headers, match condition, sampling rate and priority
Defining a mock response: status code, body, headers, match condition, sampling rate and priority
Toggling mocking globally or per service from Inspect in Flowable Work
Toggling mocking globally or per service from Inspect in Flowable Work
A mocked call, clearly badged in the execution details
A mocked call, clearly badged in the execution details
← All features