Liberate Orchestration Platform API

HTTP interface to the Liberate Orchestration Platform. Two documented operations drive workflow orchestrations authored on the Liberate canvas: starting a flow by slug with an optional JSON context, and advancing a paused workflow instance by delivering an intermediate event. Both authenticate with a bearer token issued by Liberate. Every customer is provisioned their own unique endpoint URL, in both a production and a QA environment. Synchronous flows return the flow's end output; asynchronous flows return a status and Instance ID immediately and may run for days, pausing at intermediate events for external systems or human decisions.

Documentation

Specifications

Other Resources

OpenAPI Specification

liberate-innovations-orchestration-openapi.yml Raw ↑
openapi: 3.1.0
info:
  title: Liberate Orchestration Platform API
  version: '1.0'
  summary: Trigger and advance Liberate workflow orchestrations over HTTP.
  description: |
    The Liberate Orchestration Platform exposes a small HTTP surface for driving workflow
    orchestrations built on the Liberate canvas. Two operations are publicly documented on the
    Liberate developer hub:

      * Starting a workflow (a "Start Event") by PUTting a flow `slug` plus an optional `context`
        object to the customer's integration endpoint.
      * Advancing a paused workflow instance by POSTing an intermediate `event` (plus the
        `instanceId` and optional `context`) to `/xmanager/event`.

    Every Liberate customer is issued their own unique endpoint URL, and every customer has both a
    production and a QA environment. The exact curl invocation for a given workflow is shown in the
    properties panel of that workflow's Start Event inside the Liberate application. The server URL
    below is the production example published in the documentation; substitute your tenant's URL.

    Authentication is a bearer token issued by Liberate.

    NOTE ON PROVENANCE: Liberate does not publish a machine-readable OpenAPI description. This
    definition was generated by the API Evangelist enrichment pipeline strictly from the request
    and response semantics documented on https://docs.liberateinc.com/. Only documented paths,
    methods, headers, and body fields are represented here; nothing has been invented. Response
    schemas are intentionally loose because the documentation states the response "will depend on
    the logic and implementation of the flow itself."
  termsOfService: https://www.liberateinc.com/legal/terms-of-service
  contact:
    name: Liberate Support
    url: https://www.liberateinc.com/request-demo
  x-provenance:
    generated: '2026-07-19'
    method: generated
    source:
      - https://docs.liberateinc.com/docs/calling-a-workflow
      - https://docs.liberateinc.com/docs/calling-a-workflow-with-context
      - https://docs.liberateinc.com/docs/intermediate-events
      - https://docs.liberateinc.com/docs/liberate-workflow-types
externalDocs:
  description: Liberate Orchestration Platform developer hub
  url: https://docs.liberateinc.com/
servers:
  - url: https://integration.liberateinc.io
    description: >-
      Production example published in the documentation. Each Liberate customer is assigned their
      own unique endpoint URL; find yours in the Start Event curl example for your workflow.
    x-environment: production
    x-per-tenant: true
tags:
  - name: Workflows
    description: Start workflow orchestrations and pass context data into them.
  - name: Events
    description: Advance workflow instances that are paused on an intermediate event.
security:
  - bearerAuth: []
paths:
  /:
    put:
      operationId: startWorkflow
      summary: Start a workflow
      description: |
        Triggers a Liberate flow. The request body carries the flow `slug` (the workflow identifier)
        and a `context` object holding any initial data the workflow should start with. Context data
        supplied here is automatically written into the workflow context and becomes available to
        every downstream component.

        Synchronous flows respond immediately with a status code and instance ID and continue to run
        to completion, returning the end output of the flow as the response. Asynchronous flows also
        respond immediately with a status code and instance ID, then continue running in the
        background — potentially for minutes, hours, or days — while awaiting intermediate events or
        human interaction.
      tags:
        - Workflows
      security:
        - bearerAuth: []
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/StartWorkflowRequest'
            examples:
              minimal:
                summary: Start a flow with no initial context
                value:
                  slug: simple-flow-d9379aa1-2508-49a2-b7be-7537013535f0
                  context: {}
              withContext:
                summary: Start a first-notice-of-loss flow with collected session data
                value:
                  slug: simple-flow-d9379aa1-2508-49a2-b7be-7537013535f0
                  context:
                    session:
                      hubRadio: file_a_claim
                      propertyFnolLob: home
                      propertyLocation: elm
                      propertyFnolLossType: weather
                      propertyFnolLossCause: hurricane
                      aleRadio: 'no'
                      propertyFnolLossDescriptionInput: long description.......
      responses:
        '200':
          description: >-
            The workflow was accepted. Synchronous flows return the end output of the flow;
            asynchronous flows return a status and the instance ID of the newly created session.
            The concrete shape depends on the logic of the triggered flow.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/WorkflowAcknowledgement'
        '401':
          description: Missing or invalid bearer token.
  /xmanager/event:
    post:
      operationId: sendIntermediateEvent
      summary: Send an intermediate event to a running workflow instance
      description: |
        Advances a workflow instance that is paused on an Intermediate Event. Intermediate events
        act as synchronization points, letting a workflow wait on an asynchronous operation, an
        external system response, or a human-in-the-loop decision before proceeding.

        The payload carries the `instanceId` of the paused workflow session, the `event` message
        describing the event or operation, and optionally a `context` object with data relevant to
        the event. Once received, the workflow continues with the following step; an optional action
        name and action transformation can reshape the delivered data into the workflow context.
      tags:
        - Events
      security:
        - bearerAuth: []
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/IntermediateEventRequest'
            examples:
              default:
                summary: Deliver an event to a paused instance
                value:
                  instanceId: <your instance id>
                  event: <your event message here>
                  context: {}
      responses:
        '200':
          description: The event was delivered and the workflow instance resumed.
        '401':
          description: Missing or invalid bearer token.
components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      description: >-
        A unique bearer token obtained from Liberate, sent in the Authorization header as
        `Authorization: Bearer <token>`. Tokens are issued per customer and per environment
        (production and QA).
  schemas:
    StartWorkflowRequest:
      type: object
      required:
        - slug
      properties:
        slug:
          type: string
          description: >-
            The flow's slug or identifier. Found in the Start Event properties of the workflow on
            the Liberate canvas.
          examples:
            - simple-flow-d9379aa1-2508-49a2-b7be-7537013535f0
        context:
          $ref: '#/components/schemas/Context'
    IntermediateEventRequest:
      type: object
      required:
        - instanceId
        - event
      properties:
        instanceId:
          type: string
          description: >-
            The unique Instance ID of the running workflow session, assigned when the workflow was
            started.
        event:
          type: string
          description: The event message describing the event or operation that has occurred.
        context:
          $ref: '#/components/schemas/Context'
    Context:
      type: object
      additionalProperties: true
      description: >-
        Free-form JSON carrying the state of the automation process. Context is initialized at the
        start of a workflow and written to during execution by tasks, events, decision tables, and
        intermediate events. Values are addressed downstream with JSONata expressions such as
        `$.actionName.{jsonobject}`.
    WorkflowAcknowledgement:
      type: object
      additionalProperties: true
      description: >-
        Loosely typed because the documentation states the response depends on the logic and
        implementation of the triggered flow. Both synchronous and asynchronous flows are documented
        as responding with a status code and an instance ID.
      properties:
        instanceId:
          type: string
          description: >-
            Unique identifier for this workflow session. Used to correlate reporting and to target
            the workflow with intermediate events.
        correlationId:
          type: string
          description: >-
            Identifier of the parent workflow acting as orchestrator, grouping related workflow
            instances invoked through Workflow Instance Tasks.