Overview

Owned by Cam Mackay
Last updated: Aug 07, 2024
3 min read

Technical

The Workbench API is a REST API, using the standard JSON data format over the HTTP protocol. You use JSON objects and HTTP methods like GET, POST, PUT, and DELETE to interact with resources in Workbench. The API is published to the OpenAPI specification, so there is a formal definition of the complete API as a JSON object which can be used by various tools to generate client code.

To see the current Workbench OpenAPI definition, go to [swagger]. The Swagger UI app is embedded into Web Workbench and shows a complete list of all endpoints and supported operations, as well as providing an interactive client to test them in the browser in real time. This is usually a good place to start getting familiar with the Workbench API.

Releases of the Workbench API come bundled with releases of Web Workbench, so the share the same version numbers and release schedule.

Structure

The Workbench API covers most of the functionality available in Web Workbench. The API is form-based, meaning an endpoint will usually correspond to a specific screen or form in Web Workbench and share the same business logic. Generally speaking there are 2 different types of endpoints: 'List' and 'Detail'.

List Endpoints

These endpoints end with the suffix ‘List’, and they return a paged list of resources. They only support the POST HTTP method because a JSON predicate object must be provided in the body of the request, which filters and sorts the returned data. Usually no query parameters are required.

Predicate

 

Response

 

Detail Endpoints

These endpoints end with the suffix ‘Detail’, and provide detailed information on specific items. They expose the CRUD operations of a resource and so usually support the GET, POST, and DELETE HTTP methods. These operations are symmetric, meaning that they share the same JSON data structure. So that the response from a GET request can be modified and used as the body of a POST request to update the resource.

Scaffold Endpoints

There are 2 special endpoints that provide direct access to Workbench database tables in a generalized way: TableApi and TableRowApi. This can be a really powerful tool in certain situations, but can also be quite risky. You can perform CRUD operations to database records without going through standard business logic.

TableApi

This is a ‘List’ endpoint, which accepts a predicate like object and returns a filtered list of database rows.

TableRowApi

This is a ‘Detail’ endpoint, which provides access to a particular database row.

User

Most API operation are performed as the logged in user (i.e. the Workbench user that was logged in when the the client token for the authentication header was generated). However, some methods will always be performed as a special Workbench Admn user. This user always has a PersonID of 1 and has access to all permissions. Some methods also accept a PersonID in the request that will be used to perform the operation. If you find some unexpected behaviour, please check the setup of the performing user.

Clients

There are multiple ways to consume the Workbench API

  • PowerShell scripts installed as recurring tasks

  • JavaScript web apps

  • NSwagStudio is part of the NSwag toolchain and can be used to generate C# client code.

Postman

Postman is an third party application that lets you test and explore web APIs without having to write code. To get up and running with the Workbench API follow these steps:

  1. Download Postman

  2. Go to the Workbench Integration Github repository and click the 'Run in Postman' button to import the Workbench Collection and Environment.

  3. Set the 'baseUrl' environment variable to your Web Workbench instance (XXX.wbi.cloud).

  4. Create an Application Client in your Web Workbench instance and generate a bearer token.

  5. Set the 'token' environment variable to the bearer token.

You can now start making API calls using Postman.