Script Library & JWT AI-generated

Every match/payload/header/account-selector field in a reaction is either JavaScript (Mozilla Rhino) or XQuery (Saxon). Both languages get a few built-in extras beyond the standard library.

Script Library

Each Service has its own Script Library page (Scripts link from the service view) with two free-form fields - a Javascript Library and an XQuery Library - for shared helper functions. Anything defined there is available to every reaction in that service, so common logic (formatting, validation, a shared lookup) doesn't need to be copy-pasted into every reaction's own script fields.

For example, a function defined once in a service's Javascript Library:

function links(n) {
  return n * (n-1) / 2;
}

...is then callable from any reaction's own script in that service, e.g. 150 * links(accounts.length).

An XQuery Library function must be declared with a local: prefix:

declare function local:links($n as xs:integer) as xs:integer {
  $n * ($n - 1) div 2
};

...and called the same way, with the prefix: 150 * local:links(count($accounts)).

JWT module

A built-in JWT JavaScript object lets a reaction sign, verify and decode JSON Web Tokens without an external library - e.g. issuing a signed token as part of a mocked login response, then verifying the same token on a subsequent "authenticated" request's match script. See CORS & Auth Basics for the full function reference, and the Complete JWT Auth Service write-up for a worked example.

Approximate matching (Soundex)

An LDAP approximate-match filter (~=) and any hand-written script needing "sounds like" comparisons can call a built-in Soundex helper rather than reimplementing phonetic matching from scratch.

Debugging a script

Most script fields carry a small Run button next to them - it executes just that one field against whatever request is currently loaded in the Debug tab, so you can iterate on a script without saving and re-sending a real request each time.