Introduction

This page presents an overview of the Crosser Control Center API. The detailed API endpoints specification is provided as an OpenAPI document below, which can be imported into tools like Postman or SwaggerHub for viewing/exploring.

crosser-cloud-openapi-nov2025.json

Note: The primary interface for interacting with Crosser Control Center is the web UI accessible at https://cloud.crosser.io. Using the API can cause irrevocable damage to your account, including flow designs and deployment. Use the API with care and at your own risk!

The Crosser Control Center API is a set of HTTP REST endpoints through which certain aspects of the Crosser platform can be integrated with other applications. All API requests are protected by tokens and require a valid account for access, see Authentication below.

The Crosser Control Center API uses JSON requests and responses.

All endpoint descriptions below reference the base URL https://cloud.crosser.io.

Authentication

The Crosser Control Center API uses bearer tokens to authenticate the requests. You need to login with your regular user credentials to obtain a token, using the /authentication/login endpoint. When using the returned token you will get access to the endpoints you have permissions for, through the role assigned in Crosser Control Center.

Authentication request:

Authentication response:

Use the returned token in the Authorization header of your API requests:

Organization ID and the /users/me endpoint

Some endpoints require the organization ID to be included in the URL. These endpoints will be changed so that the organization ID is no longer needed, until then you can use the /users/me endpoint to get your organization ID:

 

The responses to other requests may also contain the organization ID, in which case the /users/me endpoint may not be needed.

Access to multiple organizations

A user may have access to multiple organizations, the available organizations are listed on the organizations property in the response from /users/me. To switch to another organization a request must be made:

 

Date formats

All date/time values use UTC and are strings  in ISO 8601 "combined date and time representation" format: "2020-09-29T12:57:10.481896Z"

Filters

Many endpoints support filters to select a subset of the available dataset. Filters are applied through query parameters and represented as an array, to allow multiple filters in the same query. Each element in the array needs at least the following properties:

Filter specification:

Where propertyName must match one of the properties in the returned items, propertyValue is the value to check against the item values and  filterType is one of [equal, contains].

For example, if we want to just get all events belonging to the node Production5 we could use the following query parameters with the /events endpoint:

Pagination

Endpoints that potentially return a large number of items support pagination through “offset” and “limit” query parameters. These endpoints typically have a default value for the “limit” parameter, to get all items in a single request the “limit” parameter must therefore be explicitly set in the request.

The query parameter includeCount can be set to true to include the total number of items available in the response.

Data model

All data objects managed by Crosser Control Center are identified by an ID (typically a GUID). These IDs are used both in URLs when accessing a specific object, but also internally to specify relationships between objects, e.g. the modules used in a flow are represented by their IDs.

Flows

Flows are objects that combine many of the other types of objects, hence these objects are the most complex. When dealing with flows through the API, e.g. to deploy a specific flow to a node, a basic understanding of the data model is needed.

Flowdefinitions are the topmost containers for flows. A flowdefinition can contain flowdrafts (editable flow versions) and/or flows (read-only flow versions).

 

For example, if you want to deploy a flow with a certain name you need to traverse the array of flowdefinitions returned from the /flowdefinitions endpoint to find a matching name (or use filters) and note the ID, then traverse the selected flowdefinition to find a flow version or a flowDraft to use and note the corresponding ID. 

In the same way you need to use the /edgenodes endpoint to find the ID of the node matching your name.

We now have all the data necessary to deploy the flow on our node:

Note: Flowdefinitions are complex data structures and we have just touched on the basics here. We strongly recommend that you don’t modify these structures through the API, just read the data to find information needed for e.g. deployments of flows.

Example Usage

The following sections present some common endpoints and their use.

Resources

A Resource can have multiple versions. A top-level object is used to hold information common to all versions, such as Type and  Path. The content and description of a version can be changed as long as it is in the Draft state. Draft resources can only be used in remote sessions for testing. To deploy a Flow any resources used must be converted to versions (non-editable), as described below.

List available resources

Creating a new Resource

Creating a new resource is a three-step process: First a resource object is created and then a draft of the resource is created. Finally data is uploaded to the new draft. For an existing resource, only the last two steps are needed.

Create a new Resource object

To create a new resource the first step is to create the resource object. This is done by providing the necessary information in a POST request:

Fields:

The response contains the ID of the created object in the ‘id’ property. The next step is to create a draft or a version.

Creating a draft of the Resource

To create a draft the following request is used:

Fields:

 

The response contains the id of the created draft, this id is used in the next request when uploading data.

Uploading data to a draft

The next step is to upload the data using a multipart/form-data POST request against the following endpoint:

Fields:

Convert a draft to a version

To convert a draft to a version (versions cannot be modified) make the following request:

Note that the response when generating the draft, or when making a GET request to get the draft information, can be used in the above request by just changing the value of the state field.

Delete a resource (including all versions/drafts)

Note that a resource can only be deleted if none of the versions are used in any Flow, FlowApp or parameter.

Delete a draft or version of a resource

Note that only versions that are not used in any Flow, FlowApp or parameter can be deleted.

Nodes

Create a new Node

The response will contain id and accessKey that you will need when configuring the Node (id = nodeId when configuring the Node). Note: This is the only time you will get the accessKey, so make sure to store it somewhere.

Get information about a node

Without the {id} you will get a list of all Nodes.

Delete a Node

Events

Events from both Nodes/Flows and the Control Center are accessed through the ‘/events’ endpoint. Typically you would want to apply some filters to limit the number of events returned.

For example, to get all Error events since 2024-01-18T15:00:00, the following request can be used:

 

Identity Provider

Update client credentials

Update client credentials of your Identity Provider  client application in i.e. Microsoft Entra ID.

Fields: