...

The Workbench API covers most of the functionality available in Web Workbench. An API 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’. The , 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

API Operations will usually be Most API operation are performed as the authenticating logged in user (i.e. the Workbench account user that was used in authentication).

For example…

However, some endpoints…

...

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:

...

You can now start making API calls using Postman.

...