Quick Start

Learn how to quickly get started with the Keyfax REST based Web API.

This is a quick start guide intended to help developers integrating Keyfax into an existing housing management system or tenant portal. This quick start guide is intended to get you up and running as quickly as possible and as such only details the minimal steps necessary for host systems to launch Keyfax and process Keyfax results.

Some more advanced concepts are not covered in this guide. For further information please refer to the "Additional Reading" section below for links to our full integration documentation.

Verification Methods

Certain requests into the Keyfax REST based Web API require verification. We support 3 types of verification, these are Basic, Bearer and API Key. Verification is achieved by providing a Authorization header with each request. An example Authorization header is shown below for each supported verification method.

Basic

  • Basic verification is primarily used by native applications or for server-to-server communication where you can secure the private signing key. This is the most secure verification method. All API requests are signed with the private signing key via a pre-flight request to the server and the resulting signature is then sent along with the real request. The signature is then generated again on the server and compared with the sent signature. The public API key must also match.

  • Authorization: Basic {hostName}:{publicKey}:{signature}

Bearer

  • Bearer verification is intended for client side scenarios were it's not possible to hide a private key. Bearer tokens are typically short lived. The /api/v1/tokens end point can be used to generate a short lived JSON web token which can be used with the Bearer verification method. This is the preferred approach to ensure verified client side requests.

  • Authorization: Bearer {hostName}:{bearerToken}

API Key

NOTE The API Key verification method is only available with Keyfax version 4.4.0 and above. If your trying to use this verification method with an earlier version of Keyfax you’ll see a 401Unauthorized response.

  • API Key uses a static API key to allow requests - this can be used both server and client side. Requests using this approach are not considered verified as the API key could be visible to anyone. We offer this option for those that are not able to execute server side code to generate an initial bearer token for client side requests.

  • Authorization: ApiKey {hostName}:{apiKey}

The hostName would typically be Default, Dev, Test or Live depending on the hostName supplied during initial key creation or when calling /api/v1/key?hostName={hostName} to create the initial key. (see below).

1. Obtaining a Keyfax API Key

Make a request to /interview/api/v1/key?hostName=Live to obtain an initial API key. This will provide the response shown below (with different keys)...

TIP By default as of Keyfax 4.4.6 and below the created API keys will be added to the database defined within the default Keyfax configuration. For Keyfax 4.4.7 and above to use a specific Keyfax configuration you can optionally specify a co querystring paramater with the above request to use a specific Keyfax configuration & database. For example /interview/api/v1/key?hostName=Test&co=Keyfax_Staff_Test

Make a note of the returned apiKey, signingKey & hostName - you will need these for subsequent API requests that require verification. It's worth noting a request to api/v1/key will only work if keys don't already exists for the supplied host name. If keys already exists for the supplied host name new keys will not be created.

To keep things simple for the rest of this example we'll be using the simplest static API Key verification method.

2. Returning a Keyfax Launch URL

Once you have your API key you can make verified POST request into /api/v1/startup supplying Keyfax start-up data to get back a unique URL you can use to launch a Keyfax session. An example request with minimal example Keyfax start-up data is provided below...

POST /api/v1/startup

Headers

Body

You'll notice as part of the start-up data supplied to Keyfax we provide a returnUrl property. If provided Keyfax will return to this URL after the Keyfax script is completed. Hosts would typically then perform additional post-processing of Keyfax results upon this returnUrl page.

The above request will return the following response...

You can then use the launchUrl returned within the response to open a Keyfax session for the tenant or agent. The Keyfax session can be opened in the same browser window, a new tab or a separate pop-up window.

Once the tenant or agent has completed the Keyfax script they will be automatically redirected to the returnUrl supplied within the start-up data provided to Keyfax. When redirecting back to the returnUrl Keyfax will add a unique identifier to the end of the returnUrl. This identifier can be used upon the returnUrl page to obtain Keyfax results.

3. Obtaining Keyfax Results

Upon the user being redirected back to the returnUrl page you would make the below API request upon the returnUrl page to retrieve Keyfax results. The GUID within the request body would be obtained from the guid querystring parameter appending to the returnUrl page.

POST /api/v1/results

Headers

Body

The /api/v1/results end-point will return Keyfax results containing all of the information related to the completed Keyfax session. An example response from /api/v1/results is shown below...

Host systems would typically perform additional processing of the results produced by Keyfax. For example you may wish to parse the SOR codes or overall priority and associate these with a work item or order within your system.

Example Data

Minimal Start Up Data Examples

The below illustrates the minimum start-up data you must post to Keyfax via /api/v1/startup. This is only to serve as an example and to show what's possible. Host systems would typically work with Omfax Systems to craft this start-up data based on your specific requirements & configuration.

Staff (RD / FL)

Online (ROL / EOL)

Full Start- Up Data Examples

The below illustrates some realistic start-up data you would typically post to Keyfax via /api/v1/startup. This is only to serve as an example and to show what's possible. Host systems would typically work with Omfax Systems to craft this start-up data based on your specific requirements & configuration.

Staff (RD/FL)

Online (ROL/EOL)

Custom Start-Up Data

You can supply custom / non-standard fields within the Keyfax start-up JSON using the customData property as shown below...

This will be converted to the following start-up XML...

This would then be accessible within Keyfax via Import Databoxes (i.e. Startup/CustomData/CustomRoot1/CustomRoot1_Child1/text() would return "Child 1 Value").

You can also nest custom properties as demonstrated below...

This will produce the following start-up XML...

Custom Start Up Data Example

Consider the following start-up JSON...

This would actually be supplied to Keyfax as XML in the form...

So to access values within the <CustomData/> element you can use XPath expressions within existing Import Databoxes as shown below...

Accessing start-up data via a "Import" Databox

For additional information please see our Deep Diveor API Reference.

Last updated