API Reference
Connect API
- Introduction
- Endpoints
- Protocol (HTTP)
- Connectors
- Connector Versions
- Connections
- Actions
- Triggers
- Definitions
- Protocols
- Miscellaneous
Embedded API
- Introduction
- Endpoints
Organisations API
- Overview
- Signing Keys
Import HTTP Connector
ImportHTTPConnector imports a Connector from another format such as OpenAPI or Postman Collections.
The Connector will be created in a draft state and will need to be published before it can be used in a live board.
Authorizations
Bearer token authentication used by the Versori Platform. External consumers must provide an API key, however internal consumers must provide a JWT id_token issued by our IdP.
Path Parameters
Body
The file to be imported.
ImportHTTPConnectorMetadata defines the metadata part of the multipart/form-data request when importing a Connector from another format.
The format of the file to be imported.
openapi- OpenAPI 3.x specification, we may include support for 2.x in the future.
openapi Response
ImportHTTPConnectorResult defines the result of importing a Connector from an external format, such as OpenAPI.
ID is the unique identifier of the Action.
HTTPMethod defines the HTTP method which will be used when invoking the Action. This is typically one of the standard HTTP methods such as GET, POST, PUT, PATCH or DELETE, but may be any valid HTTP method.
GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, CONNECT, TRACE Name is a unique identifier for the Action within the scope of the Connector. It is expected to both human and machine-readable, i.e. "GetProduct" or "get_products", see the validation regex for more details.
cookie, header, path, query Name is the name of the parameter which will be sent to the HTTP endpoint.
Required denotes whether this parameter is required.
Type is the type of the parameter. Currently only scalar types are supported, if you require complex types then get in touch with support to discuss options.
string, number, integer, boolean ActionCompletion defines how an Action may be completed by Switchboard to aid the user in selecting a valid value. Schema TBD.
Default is the default value to use for the parameter if no value is provided by the user. If this is not defined then the parameter will not be sent to the HTTP endpoint if no value is explicitly provided by the user.
If this value is a string, it may be templated using a Go-formatted template
string, i.e. {{ .conn.foo }} where foo is an connection variable defined in the
Connector's Connection.
ActionPath is appended to the Connector's base URL to build the full URL to send requests to. It may also contain placeholders to inject dynamic values from the following sources:
{{ param.<name> }}- Injects the value of the parameter with the given name.{{ conn.<name> }}- Injects the value of the connection variable with the given name.
Responses defines the expected responses from the HTTP endpoint. This is used to determine whether the Action was successful or not.
An Action may support one Definition per media-type, i.e. application/json or application/xml etc. Attempts to link multiple Definitions with the same media-type will result in an error.
Definition describes a single definition of a type which is used by the Connector. The schema language used is dependent on the media-type of the Definition, for example JSON Schema is used for media-types application/json.
Accept indicates which content types, expressed as MIME types, that this definition can accept. This value is analogous to the Accept HTTP header, as defined in RFC 7231, section 5.3.2, except each type is defined in a separate array element, rather than as a comma-separated list.
This does not represent the content type of the schema body itself, but the data which conforms to this
definition. For example, an API may respond in JSON or YAML, but the schema may be a YAML-formatted JSON
Schema. In this case, the Definition's accept field could be ["application/json", "text/yaml"] and
schema.contentType will be application/schema+yaml.
ID is the unique identifier of the Definition.
Name is a unique identifier for the Definition within the scope of the Connector. It is expected to both human and machine-readable, i.e. "Product" or "product_variant".
URL is the location of the actual Schema definition for this Definition entity.
The structure of this URL will be consistent across all media types for each connection, for example:
https://platform.versori.com/api/schemas/v1/o/{organisation_id}/{connector_id}/{connector_version}/{definition_slug}.{media_type_ext}
Description is a human-friendly description of the Definition. This is typically used to describe the purpose of the Definition and how it should be used.
ReferencedBy is a list of DefinitionReference objects which defines what other entities are referencing the this Definition.
ID is a unique identifier for the request body within the scope of the Action.
Status is the HTTP status code which is expected from the HTTP endpoint. If this is not defined then this response is treated as the default response, i.e. if no other response matches then this response will be used. An action may only have one default response and each response must have a unique status code.
http Description is a human-readable description of the Action. It can provide extra information to users about how the Action operates and anything the user may need to be aware of when using it.
Errors is a list of ErrorField objects which defines the errors which may be returned by the Action. An empty array denotes that the Action has been validated and no errors were found. If this field is undefined then this means validation has not occurred.
Field is the field which failed validation. This is typically a JSON Pointer, i.e. "/parameters/0/properties/id", however this is open for discussion (we should be consistent with the ErrorField type).
Message is a human-readable description of the error. This is typically a human-readable string, i.e. "The parameter 'id' is invalid".
Severity is the severity of the error. This is used to determine how the error should be displayed to the user, i.e. a warning may be displayed in a modal dialog, whereas an error may be displayed inline.
error, warning ActionHTTPRequestBody defines whether a request body is required for a particular HTTP Action, and if so which Definitions are considered valid. If this value is undefined then no request body will be sent.
An Action may support one Definition per media-type, i.e. application/json or application/xml etc. Attempts to link multiple Definitions with the same media-type will result in an error.
Definition describes a single definition of a type which is used by the Connector. The schema language used is dependent on the media-type of the Definition, for example JSON Schema is used for media-types application/json.
Accept indicates which content types, expressed as MIME types, that this definition can accept. This value is analogous to the Accept HTTP header, as defined in RFC 7231, section 5.3.2, except each type is defined in a separate array element, rather than as a comma-separated list.
This does not represent the content type of the schema body itself, but the data which conforms to this
definition. For example, an API may respond in JSON or YAML, but the schema may be a YAML-formatted JSON
Schema. In this case, the Definition's accept field could be ["application/json", "text/yaml"] and
schema.contentType will be application/schema+yaml.
ID is the unique identifier of the Definition.
Name is a unique identifier for the Definition within the scope of the Connector. It is expected to both human and machine-readable, i.e. "Product" or "product_variant".
URL is the location of the actual Schema definition for this Definition entity.
The structure of this URL will be consistent across all media types for each connection, for example:
https://platform.versori.com/api/schemas/v1/o/{organisation_id}/{connector_id}/{connector_version}/{definition_slug}.{media_type_ext}
Description is a human-friendly description of the Definition. This is typically used to describe the purpose of the Definition and how it should be used.
ReferencedBy is a list of DefinitionReference objects which defines what other entities are referencing the this Definition.
ID is a unique identifier for the request body within the scope of the Action.
Required denotes whether a request body is required for this Action.
Summary is a human-readable version of the id field, i.e. "Get Product" or "Get Products". This is used
when displaying the Action to users, however if omitted the actionId can be used to display to users
instead.
HTTPConnector represents a connector to an external system over HTTP.
Description enables users to distinguish multiple configurations which use the same schemeType.
ID is the unique identifier of the AuthSchemeConfig, this is generated by the client and only requires to be unique amongst the elements of the array in which is it contained.
"none"ValidationMessages is a list of messages which are generated when the AuthSchemeConfig is validated. This is typically used to provide feedback to the user when they are creating or updating the AuthSchemeConfig.
This field will be ignored if sent to the API.
info, warning, error Text contains the text of the message.
Details contains additional information about the message. This is intended to be used to provide more information about the message, such as a list of validation errors.
BaseURL is the base URL of all HTTP Actions within the Connector.
Connections is a list of all the connections this Connector has.
CreatedAt is the time the Connection was created.
ConnectionCredentials defines the Action and Trigger credentials for the owning Connector. If multiple credentials are defined for each type, they are applied to the request in the order they are defined. This is to enable Connectors which require both a user session token and an API key to be provided in the request.
AuthSchemeConfig defines how a Connector implements the AuthScheme in order to fulfil its authentication requirements. This is purely the configuration and not the actual credential which is used to authenticate. The credential uses this configuration to determine how to authenticate.
CredentialBase is the base type for all credentials. It contains the common properties which are shared across all credential types.
AuthSchemeConfig defines how a Connector implements the AuthScheme in order to fulfil its authentication requirements. This is purely the configuration and not the actual credential which is used to authenticate. The credential uses this configuration to determine how to authenticate.
CredentialBase is the base type for all credentials. It contains the common properties which are shared across all credential types.
ID is the unique identifier of the Connection. Typically this is only used internally and most (if not all)
public-facing APIs will use the name in combination with the Connector's id instead.
Name is the name of the Connection. This must be unique within the owning Connector.
UpdatedAt is the time the Connection was last updated.
CreatedAt is the time at which the ConnectorVersion was created.
ID is the unique identifier of the Connector.
Name is the user-provided name of the Connector
OrganisationID is the unique identifier of the Organisation that owns the Connector.
ProtocolType denotes the set of all valid connector types.
http, bigquery UpdatedAt is the time at which the ConnectorVersion was last updated, including any changes to child resources.
Versions is a list of all the versions this Connector has.
CreatedAt is the time at which the ConnectorVersion was created.
ID is the unique identifier of the ConnectorVersion, this is typically only used internally and the version
name is used externally in combination with the Connector id.
IsDefault denotes whether this is the default version of the Connector.
IsLatest denotes whether this is the latest version of the Connector.
Name denotes the actual version value for the Connector. This can be any value but a consistent naming strategy is recommended, such as SemVer, CalVer or an incrementing number. The names "default" and "latest" are reserved words and cannot be used.
PublishedAt is the time at which the ConnectorVersion was published.
UpdatedAt is the time at which the ConnectorVersion was last updated, including any changes to child resources.
Description allows specifying additional information about the ConnectorVersion, such as what changed since the last version etc.
info, warning, error Text contains the text of the message.
Details contains additional information about the message. This is intended to be used to provide more information about the message, such as a list of validation errors.
Hold an optional link to the documentation for the API.
The URL for the icon for the connector
Accept indicates which content types, expressed as MIME types, that this definition can accept. This value is analogous to the Accept HTTP header, as defined in RFC 7231, section 5.3.2, except each type is defined in a separate array element, rather than as a comma-separated list.
This does not represent the content type of the schema body itself, but the data which conforms to this
definition. For example, an API may respond in JSON or YAML, but the schema may be a YAML-formatted JSON
Schema. In this case, the Definition's accept field could be ["application/json", "text/yaml"] and
schema.contentType will be application/schema+yaml.
ID is the unique identifier of the Definition.
Name is a unique identifier for the Definition within the scope of the Connector. It is expected to both human and machine-readable, i.e. "Product" or "product_variant".
URL is the location of the actual Schema definition for this Definition entity.
The structure of this URL will be consistent across all media types for each connection, for example:
https://platform.versori.com/api/schemas/v1/o/{organisation_id}/{connector_id}/{connector_version}/{definition_slug}.{media_type_ext}
Description is a human-friendly description of the Definition. This is typically used to describe the purpose of the Definition and how it should be used.
ReferencedBy is a list of DefinitionReference objects which defines what other entities are referencing the this Definition.
ID is the unique identifier of the Definition/Action/Trigger.
Name is unique identifier for the Definition/Action/Trigger within the scope of the Connector. It is expected to both human and machine-readable, i.e. "ProductFeature" or "stock_item".
definition, action, trigger info, warning, error Text contains the text of the message.
Details contains additional information about the message. This is intended to be used to provide more information about the message, such as a list of validation errors.
ID is the unique identifier of the Trigger.
HTTPMethod defines the HTTP method which will be used when invoking the Action. This is typically one of the standard HTTP methods such as GET, POST, PUT, PATCH or DELETE, but may be any valid HTTP method.
GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, CONNECT, TRACE Name is a unique identifier for the Trigger within the scope of the Connector. It is expected to both human and machine-readable, i.e. "GetProduct" or "get_products", see the validation regex for more details.
cookie, header, query Name is the name of the parameter which will be sent to the HTTP endpoint.
Required denotes whether this parameter is required.
Type is the type of the parameter. Currently only scalar types are supported, if you require complex types then get in touch with support to discuss options.
string, number, integer, boolean Default is the default value to use for the parameter if no value is provided by the user. If this is not defined then the parameter will not be sent to the HTTP endpoint if no value is explicitly provided by the user.
If this value is a string, it may be templated using a Go-formatted template
string, i.e. {{ .conn.foo }} where foo is an connection variable defined in the
Connector's Connection.
Responses defines the expected responses from the HTTP endpoint. This is used to determine whether the Trigger was successful or not.
a Trigger may support one Definition per media-type, i.e. application/json or application/xml etc. Attempts to link multiple Definitions with the same media-type will result in an error.
Definition describes a single definition of a type which is used by the Connector. The schema language used is dependent on the media-type of the Definition, for example JSON Schema is used for media-types application/json.
Accept indicates which content types, expressed as MIME types, that this definition can accept. This value is analogous to the Accept HTTP header, as defined in RFC 7231, section 5.3.2, except each type is defined in a separate array element, rather than as a comma-separated list.
This does not represent the content type of the schema body itself, but the data which conforms to this
definition. For example, an API may respond in JSON or YAML, but the schema may be a YAML-formatted JSON
Schema. In this case, the Definition's accept field could be ["application/json", "text/yaml"] and
schema.contentType will be application/schema+yaml.
ID is the unique identifier of the Definition.
Name is a unique identifier for the Definition within the scope of the Connector. It is expected to both human and machine-readable, i.e. "Product" or "product_variant".
URL is the location of the actual Schema definition for this Definition entity.
The structure of this URL will be consistent across all media types for each connection, for example:
https://platform.versori.com/api/schemas/v1/o/{organisation_id}/{connector_id}/{connector_version}/{definition_slug}.{media_type_ext}
Description is a human-friendly description of the Definition. This is typically used to describe the purpose of the Definition and how it should be used.
ReferencedBy is a list of DefinitionReference objects which defines what other entities are referencing the this Definition.
ID is a unique identifier for the request body within the scope of the Trigger.
Status is the HTTP status code which is expected from the HTTP endpoint. If this is not defined then this response is treated as the default response, i.e. if no other response matches then this response will be used. a Trigger may only have one default response and each response must have a unique status code.
http Description is a human-readable description of the Trigger. It can provide extra information to users about how the Trigger operates and anything the user may need to be aware of when using it.
Errors is a list of ErrorField objects which defines the errors which may be returned by the Trigger. An empty array denotes that the Trigger has been validated and no errors were found. If this field is undefined then this means validation has not occurred.
Field is the field which failed validation. This is typically a JSON Pointer, i.e. "/parameters/0/properties/id", however this is open for discussion (we should be consistent with the ErrorField type).
Message is a human-readable description of the error. This is typically a human-readable string, i.e. "The parameter 'id' is invalid".
Severity is the severity of the error. This is used to determine how the error should be displayed to the user, i.e. a warning may be displayed in a modal dialog, whereas an error may be displayed inline.
error, warning TriggerHTTPRequestBody defines whether a request body is required for a particular HTTP Trigger, and if so which Definitions are considered valid. If this value is undefined then no request body will be sent.
a Trigger may support one Definition per media-type, i.e. application/json or application/xml etc. Attempts to link multiple Definitions with the same media-type will result in an error.
Definition describes a single definition of a type which is used by the Connector. The schema language used is dependent on the media-type of the Definition, for example JSON Schema is used for media-types application/json.
Accept indicates which content types, expressed as MIME types, that this definition can accept. This value is analogous to the Accept HTTP header, as defined in RFC 7231, section 5.3.2, except each type is defined in a separate array element, rather than as a comma-separated list.
This does not represent the content type of the schema body itself, but the data which conforms to this
definition. For example, an API may respond in JSON or YAML, but the schema may be a YAML-formatted JSON
Schema. In this case, the Definition's accept field could be ["application/json", "text/yaml"] and
schema.contentType will be application/schema+yaml.
ID is the unique identifier of the Definition.
Name is a unique identifier for the Definition within the scope of the Connector. It is expected to both human and machine-readable, i.e. "Product" or "product_variant".
URL is the location of the actual Schema definition for this Definition entity.
The structure of this URL will be consistent across all media types for each connection, for example:
https://platform.versori.com/api/schemas/v1/o/{organisation_id}/{connector_id}/{connector_version}/{definition_slug}.{media_type_ext}
Description is a human-friendly description of the Definition. This is typically used to describe the purpose of the Definition and how it should be used.
ReferencedBy is a list of DefinitionReference objects which defines what other entities are referencing the this Definition.
ID is a unique identifier for the request body within the scope of the Trigger.
Required denotes whether a request body is required for this Trigger.
Summary is a human-readable version of the id field, i.e. "Get Product" or "Get Products". This is used
when displaying the Trigger to users, however if omitted the TriggerId can be used to display to users
instead.