Using the developer console

Accessing Gospel through the API

All functionality in Gospel is available through our standards-based, REST-ful API. Indeed, all our own interfaces use our own API and there are no private methods. Swagger format documentation for the API can be accessed at Gospel Core API page and we provide a selection of fully documented, easy to use SDKs for popular languages to aid integration with your products and systems.

Authorisation in the API

In order to verify requests throughout their lifecycle, all requests are signed cryptographically using a consistently repeatable algorithm. A formal description of that algorithm is available on request, but we strongly recommend using the ready-built implementations we provide within our SDKs as it has been fully tested against the version running within the Gospel core.

Obtaining Gospel SDKs and documentation

All Gospel SDKs and their docs are hosted on Gospel's Artifactory server, Gospel artifact repository, access to which can be given to current clients on request. In addition, you can refer to the to which access can be granted on request. Direct links to documentation and SDKs are provided within the UI in Gospel on the Dashboard > Downloads and Dashboard Documentation pages.

Searching in the API

To search in the API, append the parameter withAny or withAll to perform an OR or AND match on any call to a GET endpoint. The format of these parameters is a comma-delimited set of standard Gospel matchers with predicate. 

Matching syntax

Essentially, matching fields begin with one of the following:

recordThe current record context - in a trigger, the thing that triggered it; in a view, the base record
records.recordDefinitionId.recordIdA record accessed by ID
records.recordDefinitionId.withAny(matchers)A set of records matching any condition
records.recordDefinitionId.withAll(matchers)A set of records matching all conditions
<aliasName>The record matched by an alias in a view
parentThe contextual parent of the current record

Within a record, the following can be accessed:

record.idThe ID of the record
record.actorThe last person to change the record - in a trigger, the actor of the current action
record.timestampThe approximate time of the last change 
record.fields.<fieldName>A field in the record


The following predicates may be used in matchers. The syntax is designed to closely match that of OData.

neNot equals
gtGreater than (numeric)
ltLess than (numeric)
geGreater than or equal (numeric)
leLess than or equal (numeric)
containsContains (string)
not contains Does not contain (string)
existsThe record exists
not existsThe record does not exist

The exists and not exists predicates take no right-hand side and do not require a field, with clause or aggregation.


The following aggregation functions can be used in both triggers (with a with clause) and views to aggregate data from a field.

sum()Add the values together (numeric)
mean()Average the values (numeric)
max()Find the largest value (numeric)
min()Find the smallest value (numeric)
first()Just return the oldest value
last()Just return the newest value
concat()Join string values together

Substitution syntax

Almost anywhere a field can be specified, curly bracket syntax can be used to substitute in part of it. For example, records.invoice.{record.fields.invoiceId} returns the field name from the invoice with the ID of the invoice ID field in the current record.