Self-hosted On-demand Workers API
This page described the protocol used with the Self-hosted On-demand Workers -feature to help in the development of custom On-demand Workers Provisioners.
Authentication
All requests sent by the Control Room to the On-demand Workers Provisioner are authenticated with an HMAC algorithm that relies on a secret that is shared between the two parties. The implemented algorithm is loosely based on the Signature Version 4 Signing process used by Amazon on AWS. The Calculated signature is in header x-rc-signature
In addition to the signature, a timestamp is included in the headers and the recipient must verify the timestamp is recent to protect against replay attacks.
Commands
The following are the supported commands for the On-demand Workers API. Control Room sends these commands to the HTTP(S) endpoint configured into the Control room and signs them with the HMAC algorithm described above.
- Both responses and requests with payload must be sent in
application/json
content type. - The On-demand Workers Provisioner must verify the authenticity of the message by verifying the HMAC signature was generated with the shared secret
- The On-demand Workers Provisioner must verify the timestamp of the message was generated within 15 minutes of receiving the request
- Control room must retry a request if the response code is 500
- Control room may not retry a request if the response code is 400,403
Common HTTP status codes
The On-demand Workers Provisioner must implement the sending of the following status codes for all requests.
Status code | Description |
---|---|
400 | Request not recognized |
403 | HMAC check failed |
Start Command
When receiving a start command:
- On-demand Workers Provisioner must start a runtime
- The runtime must link itself to the cloud using the
runtimeLinkToken
given in the request - The runtime must assume the runtime Id given in the request in the field
runtimeId
.
Request
Attribute | Type | Description |
---|---|---|
type | string | value is start |
workspaceId | string | workspaceId of robot |
runtimeLinkToken | string | Single use link token that the started runtime should use to link to control room |
runtimeId | string | runtimeId that the runtime should assign itself. |
maxLifetimeSeconds | number | Max lifetime of runtime in seconds. Provisioner may stop runtime if runtime is active for longer than this time. |
Response
The On-demand Workers Provisioner must implement the following status codes in addition to the common status codes.
Status code | Description |
---|---|
200 | Runtime Started |
500 | Runtime creation failed |
Stop Command
When receiving a stop command:
- The On-demand Workers Provisioner may stop the runtime execution
Request
Attribute | Type | Description |
---|---|---|
type | string | value is stop |
workspaceId | string | workspaceId of robot |
runtimeId | string | runtimeId that the runtime should assign itself. |
Response
The On-demand Workers Provisioner must implement the following status codes in addition to the common status codes.
Status code | Description |
---|---|
200 | Runtime stopped or command not implemented |
500 | Runtime stopping failed |
Status Command
Request
Attribute | Type | Description |
---|---|---|
type | string | value is status |
Response
Attribute | Type | Description |
---|---|---|
version | number | value is 1 |
status | string | 'OK' if everything is ok, error message otherwise |
Example implementation of Authentication in Python
The following is an example implementation of the HMAC and timestamp verification written in Python.