Getting Started

Introduction

The Rossum API allows you to programmatically access and manage your organization's Rossum data and account information. The API allows you to do the following programmatically:

• Manage your organization, users, workspaces and queues
• Configure captured data: select extracted fields
• Integrate Rossum with other systems: import, export, extensions

On this page, you will find an introduction to the API usage from a developer perspective, and a reference to all the API objects and methods.

Developer Resources

There are several other key resources related to implementing, integrating and extending the Rossum platform:

• Refer to the Rossum Developer Portal for guides, tutorials, news and a community Q&A section.
• Subscribe to the rossum-api-announcements group to stay up to date on the API and platform updates.
• For managing and configuring your account, use the rossum command-line tool. (Setup instructions.)
• For a management overview of Rossum implementation options, see the Rossum Integration Whitepaper.
• If you are an RPA developer, refer to our UiPath or BluePrism guides.

Quick API Tutorial

For a quick tutorial on how to authenticate, upload a document and export extracted data, see the sections below. If you want to skip this quick tutorial, continue directly to the Overview section.

It is a good idea to go through the introduction to the Rossum platform on the Developer Portal first to make sure you are up to speed on the basic Rossum concepts.

If in trouble, feel free to contact us at support@rossum.ai.

Install curl tool

Test curl is installed properly

curl https://<example>.rossum.app/api/v1

{
  "organizations":"https://<example>.rossum.app/api/v1/organizations",
  "workspaces":"https://<example>.rossum.app/api/v1/workspaces",
  "schemas":"https://<example>.rossum.app/api/v1/schemas",
  "connectors":"https://<example>.rossum.app/api/v1/connectors",
  "inboxes":"https://<example>.rossum.app/api/v1/inboxes",
  "queues":"https://<example>.rossum.app/api/v1/queues",
  "documents":"https://<example>.rossum.app/api/v1/documents",
  "users":"https://<example>.rossum.app/api/v1/users",
  "groups":"https://<example>.rossum.app/api/v1/groups",
  "annotations":"https://<example>.rossum.app/api/v1/annotations",
  "pages":"https://<example>.rossum.app/api/v1/pages"
}

All code samples included in this API documentation use curl, the command line data transfer tool. On MS Windows 10, MacOS X and most Linux distributions, curl should already be pre-installed. If not, please download it from curl.haxx.se).

Optionally use jq tool to pretty-print JSON output

curl https://<example>.rossum.app/api/v1 | jq

{
  "organizations": "https://<example>.rossum.app/api/v1/organizations",
  "workspaces": "https://<example>.rossum.app/api/v1/workspaces",
  "schemas": "https://<example>.rossum.app/api/v1/schemas",
  "connectors": "https://<example>.rossum.app/api/v1/connectors",
  "inboxes": "https://<example>.rossum.app/api/v1/inboxes",
  "queues": "https://<example>.rossum.app/api/v1/queues",
  "documents": "https://<example>.rossum.app/api/v1/documents",
  "users": "https://<example>.rossum.app/api/v1/users",
  "groups": "https://<example>.rossum.app/api/v1/groups",
  "annotations": "https://<example>.rossum.app/api/v1/annotations",
  "pages": "https://<example>.rossum.app/api/v1/pages"
}

You may also want to install jq tool to make curl output human-readable.

Use the API on Windows

This API documentation is written for usage in command line interpreters running on UNIX based operation systems (Linux and Mac). Windows users may need to use the following substitutions when working with API:

Example of API call on UNIX-based OS

curl -H 'Authorization: Bearer db313f24f5738c8e04635e036ec8a45cdd6d6b03' -H 'Content-Type: application/json' \
  -d '{"target_queue": "https://<example>.rossum.app/api/v1/queues/8236", "target_status": "to_review"}' \
  'https://<example>.rossum.app/api/v1/annotations/315777/copy'

Examples of API call on Windows

curl -H "Authorization: Bearer db313f24f5738c8e04635e036ec8a45cdd6d6b03" -H "Content-Type: application/json" ^
  -d "{""target_queue"": ""https://<example>.rossum.app/api/v1/queues/8236"", ""target_status"": ""to_review""}" ^
  "https://<example>.rossum.app/api/v1/annotations/315777/copy"


curl -H "Authorization: Bearer db313f24f5738c8e04635e036ec8a45cdd6d6b03" -H "Content-Type: application/json" ^
  -d "{\"target_queue\": \"https://<example>.rossum.app/api/v1/queues/8236\", \"target_status\": \"to_review\"}" ^
  "https://<example>.rossum.app/api/v1/annotations/315777/copy"

Create an account

In order to interact with the API, you need an account. If you do not have one, you can create one via our self-service portal.

Login to the account

Fill-in your username and password (login credentials to work with API are the same as those to log into your account.). Trigger login endpoint to obtain a key (token), that can be used in subsequent calls.

curl -s -H 'Content-Type: application/json' \
  -d '{"username": "east-west-trading-co@example.com", "password": "aCo2ohghBo8Oghai"}' \
  'https://<example>.rossum.app/api/v1/auth/login'
{"key": "db313f24f5738c8e04635e036ec8a45cdd6d6b03"}

This key will be valid for a default expire time (currently 162 hours) or until you log out from the sessions.

Upload a document

In order to upload a document (PDF, image, XLSX, XLS, DOCX, DOC) through the API, you need to obtain the id of a queue first.

curl -s -H 'Authorization: Bearer db313f24f5738c8e04635e036ec8a45cdd6d6b03'
  'https://<example>.rossum.app/api/v1/queues?page_size=1' | jq -r .results[0].url
https://<example>.rossum.app/api/v1/queues/8199

Then you can upload document to the queue. Alternatively, you can send documents to a queue-related inbox. See upload for more information about importing files.

curl -s -H 'Authorization: Bearer db313f24f5738c8e04635e036ec8a45cdd6d6b03' \
  -F content=@document.pdf 'https://<example>.rossum.app/api/v1/uploads?queue=8199' | jq -r .url
https://<example>.rossum.app/api/v1/tasks/9231

Wait for document to be ready and review extracted data

As soon as a document is uploaded, it will show up in the queue and the data extraction will begin. It may take a few seconds to several minutes to process a document. You can check status of the annotation and wait until its status is changed to to_review.

curl -s -H 'Authorization: Bearer db313f24f5738c8e04635e036ec8a45cdd6d6b03' \
  'https://<example>.rossum.app/api/v1/annotations/319668' | jq .status
"to_review"

After that, you can open the Rossum web interface example.rossum.app to review and confirm extracted data.

Download reviewed data

Now you can export extracted data using the export endpoint of the queue. You can select XML, CSV, XLSX or JSON format. For CSV, use URL like:

curl -s -H 'Authorization: Bearer db313f24f5738c8e04635e036ec8a45cdd6d6b03' \
  'https://<example>.rossum.app/api/v1/queues/8199/export?status=exported&format=csv&id=319668'
Invoice number,Invoice Date,PO Number,Due date,Vendor name,Vendor ID,Customer name,Customer ID,Total amount,
2183760194,2018-06-08,PO2231233,2018-06-08,Alza.cz a.s.,02231233,Rossum,05222322,500.00

Logout

Finally you can dispose token safely using logout endpoint:

curl -s -X POST -H 'Authorization: Bearer db313f24f5738c8e04635e036ec8a45cdd6d6b03' \
  'https://<example>.rossum.app/api/v1/auth/logout'
{"detail":"Successfully logged out."}

Overview

HTTP and REST

The Rossum API is organized around REST. Our API has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. We use built-in HTTP features, like HTTP authentication and HTTP verbs, which are understood by off-the-shelf HTTP clients.

HTTP Verbs

Call the API using the following standard HTTP methods:

• GET to retrieve an object or multiple objects in a specific category
• POST to create an object
• PUT to modify entire object
• PATCH to modify fields of the object
• DELETE to delete an object

We support cross-origin resource sharing, allowing you to interact securely with our API from a client-side web application. JSON is returned by API responses, including errors (except when another format is requested, e.g. XML).

Base URL

Base API endpoint URL depends on the account type, deployment and location. Default URL is https://<example>.rossum.app/api where the example is the domain selected during the account creation. URLs of companies using a dedicated deployment may look like https://acme.rossum.app/api.

If you are not sure about the correct URL you can navigate to https://app.rossum.ai and use your email address to receive your account information via email.

Please note that we previously recommended using the https://api.elis.rossum.ai endpoint to interact with the Rossum API, but now it is deprecated. For new integrations use the new https://<example>.rossum.app/api endpoint. For accounts created before Nov 2022 use the https://elis.rossum.ai/api.

Authentication

Most of the API endpoints require a user to be authenticated. To login to the Rossum API, post an object with username and password fields. Login returns an access key to be used for token authentication.

Our API also provide possibility to authenticate via One-Time token which is returned after registration. This tokens allows users to authenticate against our API, but after one call, this token will be invalidated. This token can be exchanged for regular access token limited only by the time of validity. For the purpose of token exchange, use the /auth/token endpoint.

Users may delete a token using the logout endpoint or automatically after a configured time (the default expiration time is 162 hours). The default expiration time can be lowered using max_token_lifetime_s field. When the token expires, 401 status is returned. Users are expected to re-login to obtain a new token.

Rossum's API also supports session authentication, where a user session is created inside cookies after login. If enabled, the session lasts 1 day until expired by itself or until logout While the session is valid there is no need to send the authentication token in every request, but the "unsafe" request (POST, PUT, PATCH, DELETE), whose MIME type is different from application/json must include X-CSRFToken header with valid CSRF token, which is returned inside Cookie while loging in. When a session expires, 401 status is returned as with token authentication, and users are expected to re-login to start a new session.

Login

Login user using username and password

curl -H 'Content-Type: application/json' \
  -d '{"username": "east-west-trading-co@<example>.rossum.app", "password": "aCo2ohghBo8Oghai"}' \
  'https://<example>.rossum.app/api/v1/auth/login'

{
  "key": "db313f24f5738c8e04635e036ec8a45cdd6d6b03",
  "domain": "acme-corp.app.rossum.ai"
}

POST /v1/auth/login

Use token key in requests

curl -H 'Authorization: Bearer db313f24f5738c8e04635e036ec8a45cdd6d6b03' \
  'https://<example>.rossum.app/api/v1/organizations/406'

Note: The Token authorization scheme is also supported for compatibility with earlier versions.

curl -H 'Authorization: Token db313f24f5738c8e04635e036ec8a45cdd6d6b03' \
  'https://<example>.rossum.app/api/v1/organizations/406'

Login user expiring after 1 hour

curl -H 'Content-Type: application/json' \
  -d '{"username": "east-west-trading-co@<example>.rossum.app", "password": "aCo2ohghBo8Oghai", "max_token_lifetime_s": 3600}' \
  'https://<example>.rossum.app/api/v1/auth/login'

{
  "key": "ltcg2p2w7o9vxju313f04rq7lcc4xu2bwso423b3",
  "domain": null
}

Response

Status: 200

Returns object with "key", which is an access token. And the user's domain.

Logout

Logout user

curl -X POST -H 'Authorization: Bearer db313f24f5738c8e04635e036ec8a45cdd6d6b03' \
  'https://<example>.rossum.app/api/v1/auth/logout'

{
  "detail": "Successfully logged out."
}

POST /v1/auth/logout

Logout user, discard auth token.

Response

Status: 200

Token Exchange

Exchange One-Time authentication token with a longer-lived access token.

curl -X POST -H 'Authorization: Bearer db313f24f5738c8e04635e036ec8a45cdd6d6b03' \
  'https://<example>.rossum.app/api/v1/auth/token'

{
  "key": "ltcg2p2w7o9vxju313f04rq7lcc4xu2bwso423b3",
  "domain": "<example>.rossum.app",
  "scope": "default"
}

POST /v1/auth/token

This endpoint enables the exchange of a one-time token for a longer lived access token.

It is able to receive either one-time tokens provided after registration, or JWT tokens if you have such a setup configured. The token must be provided in a the Bearer authorization header.

JWT authentication

Short-lived JWT tokens can be exchanged for access tokens. A typical use case, for example, is logging in your users via SSO in your own application, and displaying the Rossum app to them embedded.

To enable JWT authentication, one needs to provide Rossum with the public key that shall be used to decode the tokens. Currently only tokens with EdDSA (signed using Ed25519 and Ed448 curves) and RS512 signatures are allowed, and token validity should be 60 seconds maximum.

The expected formats of the header and encoded payload of the JWT token are as follows:

Decoded JWT Header Format

Example format of a decoded JWT token header (not encrypted)

{
   "alg":"EdDSA",
   "kid":"urn:rossum.ai:organizations:100",
   "typ":"JWT"
}

Example format of a decoded JWT token payload

{
   "ver":"1.0",
   "iss":"ACME Corporation",
   "aud":"https://<example>.rossum.app",
   "sub":"john.doe@rossum.ai",
   "exp":1514764800,
   "email":"john.doe@rossum.ai",
   "name":"John F. Doe",
   "rossum_org":"100",
   "roles": ["annotator"]
}

Decoded JWT Payload Format

Response

Status: 200

Single Sign-On (SSO)

Rossum allows customers to integrate with their own identity provider, such as Google, Azure AD or any other provider using OAuth2 OpenID Connect protocol (OIDC). Rossum then acts as a service provider.

When SSO is enabled for an organization, user is redirected to a configured identity provider login page and only allowed to access Rossum application when successfully authenticated. Identity provider user claim (e.g. email (default), sub, preferred_username, unique_name) is used to match a user account in Rossum. If auto-provisioning is enabled for the organization, user accounts in Rossum will be automatically created for users without accounts.

Required setup of the OIDC identity provider:

• Redirect URI (also known as Reply URL): https://<example>.rossum.app/api/v1/oauth/code

Required information to allow OIDC setup for the Rossum service provider:

• OIDC endpoint, such as https://accounts.google.com. It should support openid configuration, e.g. https://accounts.google.com/.well-known/openid-configuration
• client id
• client secret
• claim that should be matched in Rossum
• Rossum organization id

If you need to setup SSO for your organization, please contact support@rossum.ai.

Pagination

All object list operations are paged by default, so you may need several API calls to obtain all objects of given type.

(*) Maximum page size differs for some endpoints:

• 1,000 for exporting data in CSV format via POST on /annotations
• 500 for searching in annotations via annotations/search (if sideload=content is not included)

Filters and ordering

List queues of workspace 7540, with locale en_US and order results by name.

curl -H 'Authorization: Bearer db313f24f5738c8e04635e036ec8a45cdd6d6b03' \
  'https://<example>.rossum.app/api/v1/queues?workspace=7540&locale=en_US&ordering=name'

Lists may be filtered using various attributes. Multiple attributes are combined with & in the URL, which results in more specific response. Please refer to the particular object description.

Ordering of results may be enforced by the ordering parameter and one or more keys delimited by a comma. Preceding key with a minus sign - enforces descending order.

Metadata

Example metadata in a document object

{
  "id": 319768,
  "url": "https://<example>.rossum.app/api/v1/documents/319768",
  "s3_name": "05feca6b90d13e389c31c8fdeb7fea26",
  "annotations": [
    "https://<example>.rossum.app/api/v1/annotations/319668"
  ],
  "mime_type": "application/pdf",
  "arrived_at": "2019-02-11T19:22:33.993427Z",
  "original_file_name": "document.pdf",
  "content": "https://<example>.rossum.app/api/v1/documents/319768/content",
  "metadata": {
    "customer-id": "f205ec8a-5597-4dbb-8d66-5a53ea96cdea",
    "source": 9581,
    "authors": ["Joe Smith", "Peter Doe"]
  }
}

When working with API objects, it may be useful to attach some information to the object (e.g. customer id to a document). You can store custom JSON object in a metadata section available in most objects.

List of objects with metadata support: organization, workspace, user, queue, schema, connector, inbox, document, annotation, page, survey.

Total metadata size may be up to 4 kB per object.

Versioning

API Version is part of the URL, e.g. https://<example>.rossum.app/api/v1/users.

To allow API progress, we consider addition of a field in a JSON object as well as addition of a new item in an enum object to be backward-compatible operations that may be introduced at any time. Clients are expected to deal with such changes.

Dates

All dates fields are represented as ISO 8601 formatted strings, e.g. 2018-06-01T21:36:42.223415Z. All returned dates are in UTC timezone.

Errors

Our API uses conventional HTTP response codes to indicate the success or failure of an API request.

Import and Export

Documents may be imported into Rossum using the REST API and email gateway. Supported file formats are PDF, PNG, JPEG, TIFF, XLSX/XLS and DOCX/DOC. Maximum supported file size is 40 MB (this limit applies also to the uncompressed size of the files within a .zip archive).

In order to get the best results from Rossum the documents should be in A4 format of at least 150 DPI (in case of scans/photos). Read more about import recommendations.

Importing non-standard mime types

Support for other mime types can be added by handling upload.created webhook event. With this setup, user is able to pre-process uploaded files (e.g. XML or JSON formats) in a way which Rossum understands. Those usually need to be enabled on queue level first (by adding appropriate mimetype to accepted_mime_types in queue settings attributes). If you find your document mime types not supported please contact Rossum support team for more information.

Upload API

You can upload a document to the queue using upload endpoint with one or more files to be uploaded. You can also specify additional field values in upload endpoint, e.g. your internal document id. As soon as a document is uploaded, data extraction is started.

Upload endpoint supports basic authentication to enable easy integration with third-party systems.

Import by Email

It is also possible to send documents by email using a properly configured inbox that is associated with a queue. Users then only need to know the email address to forward emails to.

For every incoming email, Rossum extracts PDF documents, images and zip files, stores them in the queue and starts data extraction process.

The size limit for incoming emails is 50 MB (the raw email message with base64 encoded attachments).

All the files from the root of the archive are extracted. In case the root only contains one directory (and no other files) the whole directory is extracted. The zip files and all extracted files must be allowed in accepted_mime_types (see queue settings) and must pass inbox filtering rules (see document rejection conditions) in order for annotations to be created.

Small images (up to 100x100 pixels) are ignored, see inbox for reference.

You can use selected email header data (e.g. Subject) to initialize additional field values, see rir_field_names attribute description for details.

Zip attachment limits:

• the uncompressed size of the files within a .zip archive may not exceed 40 MB
• only archives containing less than 100 files are processed
• only files in the root of the archive are processed (or files inside a first level directory if it's the only one there)

Export

In order to export extracted and confirmed data you can call export endpoint. You can specify status, time-range filters and annotation id list to limit returned results.

Export endpoint supports basic authentication to enable easy integration with third-party systems.

Auto-split of document

It is possible to process a single PDF file that contains several invoices. Just insert a special separator page between the documents. You can print this page and insert it between documents while scanning.

Rossum will recognize a QR code on the page and split the PDF into individual documents automatically. Produced documents are imported to the queue, while the original document is set to a split state.

Document Schema

Every queue has an associated schema that specifies which fields will be extracted from documents as well as the structure of the data sent to connector and exported from the platform.

Rossum schema supports data fields with single values (datapoint), fields with multiple values (multivalue) or tuples of fields (tuple). At the topmost level, each schema consists of sections, which may either directly contain actual data fields (datapoints) or use nested multivalues and tuples as containers for single datapoints.

But while schema may theoretically consist of an arbitrary number of nested containers, the Rossum UI supports only certain particular combinations of datapoint types. The supported shapes are:

• simple: atomic datapoints of type number, string, date or enum
• list: simple datapoint within a multivalue
• tabular: simple datapoint within a "multivalue tuple" (a multivalue list containing a tuple for every row)

Schema content

Schema content consists of a list of section objects.

Common attributes

The following attributes are common for all schema objects:

Section

Example of a section

{
  "category": "section",
  "id": "amounts_section",
  "label": "Amounts",
  "children": [...],
  "icon": ""
}

Section represents a logical part of the document, such as amounts or vendor info. It is allowed only at the top level. Schema allows multiple sections, and there should be at least one section in the schema.

Datapoint

A datapoint represents a single value, typically a field of a document or some global document information. Fields common to all datapoint types:

rir_field_names attribute allows to specify source of initial value of the object. List items may be:

• one of extracted field types to use the AI engine prediction value
• upload:id to identify a value specified while uploading the document
• email_header:<id> to use a value extracted from email headers. Supported email headers: from, to, reply-to, subject, message-id, date.
• email_body:<id> to select email body. Supported values are text_html for HTML body or text_plain for plain text body.
• email:<id> to identify a value specified in email.received hook response

If more list items in rir_field_names are specified, the first available value will be used.

String type

Example string datapoint

{
  "category": "datapoint",
  "id": "document_id",
  "label": "Invoice ID",
  "type": "string",
  "default_value": null,
  "rir_field_names": ["document_id"],
  "constraints": {
    "length": {
      "exact": null,
      "max": 16,
      "min": null
    },
    "regexp": {
      "pattern": "^INV[0-9]+$"
    },
    "required": false
  }
}

String datapoint does not have any special attribute.

Date type

Example date datapoint

{
  "id": "item_delivered",
  "type": "date",
  "label": "Item Delivered",
  "format": "MM/DD/YYYY",
  "category": "datapoint"
}

Attributes specific to Date datapoint:

Date format supported: available tokens

Example date formats:

• D/M/YYYY: e.g. 23/1/2019
• MM/DD/YYYY: e.g. 01/23/2019
• YYYY-MM-DD: e.g. 2019-01-23 (ISO date format)

Number type

Example number datapoint

{
  "id": "item_quantity",
  "type": "number",
  "label": "Quantity",
  "format": "#,##0.#",
  "category": "datapoint"
}

Attributes specific to Number datapoint:

The following table shows numeric formats with their examples.

Aggregations

Example aggregations

{
  "id": "quantity",
  "type": "number",
  "label": "Quantity",
  "category": "datapoint",
  "aggregations": {
    "sum": {
      "label": "Total"
    }
  },
  "default_value": null,
  "rir_field_names": []
}

Aggregations allow computation of some informative values, e.g. a sum of a table column with numeric values. These are returned among messages when /v1/annotations/{id}/content/validate endpoint is called. Aggregations can be computed only for tables (multivalues of tuples).

All aggregation objects can have an attribute label that will be shown in the UI.

Enum type

Example enum datapoint with options and enum_value_type

{
  "id": "document_type",
  "type": "enum",
  "label": "Document type",
  "hidden": false,
  "category": "datapoint",
  "options": [
    {
      "label": "Invoice Received",
      "value": "21"
    },
    {
      "label": "Invoice Sent",
      "value": "22"
    },
    {
      "label": "Receipt",
      "value": "23"
    }
  ],
  "default_value": "21",
  "rir_field_names": [],
  "enum_value_type": "number"
}

Attributes specific to Enum datapoint:

Every option consists of an object with keys:

Enum datapoint value is matched in a case insensitive mode, e.g. EUR currency value returned by the AI Core Engine is matched successfully against {"value": "eur", "label": "Euro"} option.

Button type

Specifies a button shown in Rossum UI. For more details please refer to custom UI extension.

Example button datapoint

{
  "id": "show_email",
  "type": "button",
  "category": "datapoint",
  "popup_url": "http://example.com/show_customer_data",
  "can_obtain_token": true
}

Buttons cannot be direct children of multivalues (simple multivalues with buttons are not allowed. In tables, buttons are children of tuples). Despite being a datapoint object, button currently cannot hold any value. Therefore, the set of available Button datapoint attributes is limited to:

Value constraints

Example value constraints

{
  "id": "document_id",
  "type": "string",
  "label": "Invoice ID",
  "category": "datapoint",
  "constraints": {
    "length": {
      "max": 32,
      "min": 5
    },
    "required": false
  },
  "default_value": null,
  "rir_field_names": [
    "document_id"
  ]
}

Constraints limit allowed values. When constraints is not satisfied, annotation is considered invalid and cannot be exported.

UI configuration

Example UI configuration

{
  "id": "document_id",
  "type": "string",
  "label": "Invoice ID",
  "category": "datapoint",
  "ui_configuration": {
    "type":  "captured",
    "edit": "disabled"
  },
  "default_value": null,
  "rir_field_names": [
    "document_id"
  ]
}

UI configuration provides a group of settings, which alter behaviour of the field in the application. This does not affect behaviour of the field via the API. For example, disabling edit prohibits changing a value of the datapoint in the application, but the value can still be modified through API.

Logical types

• Captured field represents information retrieved by the OCR model. If combined with edit option disabled, user can't overwrite field's value, but is able to redraw field's bounding box and select another value from the document by such an action.
• Data field represents information filled by extensions. This field is not mapped to the AI model, so it does not have a bounding box, neither it's possible to create one. If combined with edit option disabled the field can't be modified from the UI.
• Manual field behaves exactly like Data field, without the mapping to extensions. This field should be used for sharing information between users or to transfer information to downstream systems.
• Formula field This field will be updated according to its formula definition, see Formula Fields. If the edit option is not disabled the field value can be overridden from the UI (see no_recalculation). This functionality is in beta.
• null value is displayed in UI as Unset and behaves similar to the Captured field.

Multivalue

Example of a multivalue:

{
  "category": "multivalue",
  "id": "line_item",
  "label": "Line Item",
  "children": {
    ...
  },
  "show_grid_by_default": false,
  "min_occurrences": null,
  "max_occurrences": null,
  "rir_field_names": null
}

Example of a multivalue with grid row-types specification:

{
  "category": "multivalue",
  "id": "line_item",
  "label": "Line Item",
  "children": {
    ...
  },
  "grid": {
    "row_types": [
      "header", "data", "footer"
    ],
    "default_row_type": "data",
    "row_types_to_extract": [
      "data"
    ]
  },
  "min_occurrences": null,
  "max_occurrences": null,
  "rir_field_names": ["line_items"]
}

Multivalue is list of datapoints or tuples of the same type. It represents a container for data with multiple occurrences (such as line items) and can contain only objects with the same id.

Multivalue grid object

Multivalue grid object allows to specify a row type for each row of the grid. For data representation of actual grid data rows see Grid object description.

For example to distinguish two header types and a footer in the validation interface, following row types may be used: header, subsection_header, data and footer.

Currently, data extraction classifies every row as either data or header (additional row types may be introduced in the future). We remove rows returned by data extraction that are not in row_types list (e.g. header by default) and are on the top/bottom of the table. When they are in the middle of the table, we mark them as skipped (null).

There are three visual modes, based on row_types quantity:

• More than two row types defined: User selects row types freely to any non-default row type. Clearing row type resets to a default row type. We support up to 6 colors to easily distinguish row types visually.
• Two row types defined (header and default): User only marks header and skipped rows. Clearing row type resets to a default row type.
• One row type defined: User is only able to mark row as skipped (null value in data). This is also a default behavior when no grid row types configuration is specified in the schema.

Tuple

Example of a tuple:

{
  "category": "tuple",
  "id": "tax_details",
  "label": "Tax Details",
  "children": [
    ...
  ],
  "rir_field_names": [
    "tax_details"
  ]
}

Container representing tabular data with related values, such as tax details. A tuple must be nested within a multivalue object, but unlike multivalue, it may consist of objects with different ids.

Updating Schema

When project evolves, it is a common practice to enhance or change the extracted field set. This is done by updating the schema object.

By design, Rossum supports multiple schema versions at the same time. However, each document annotation is related to only one of those schemas. If the schema is updated, all related document annotations are updated accordingly. See preserving data on schema change below for limitations of schema updates.

In addition, every queue is linked to a schema, which is used for all newly imported documents.

When updating a schema, there are two possible approaches:

• Update the schema object (PUT/PATCH). All related annotations will be updated to match current schema shape (even exported and deleted documents).
• Create a new schema object (POST) and link it to the queue. In such case, only newly created objects will use the current schema. All previously created objects will remain in the shape of their linked schema.

Use case 1 - Initial setting of a schema

• Situation: User is initially setting up the schema. This might be an iterative process.
• Recommendation: Edit the existing schema by updating schema (PUT) or updating part of a schema (PATCH).

Use case 2 - Updating attributes of a field (label, constraints, options, etc.)

• Situation: User is updating field, e.g. changing label, number format, constraints, enum options, hidden flag, etc.
• Recommendation: Edit existing schema (see Use case 1).

Use case 3 - Adding new field to a schema, even for already imported documents.

• Situation: User is extending a production schema by adding a new field. Moreover, user would like to see all annotations (to_review, postponed, exported, deleted, etc. states) in the look of the newly extended schema.
• Recommendation: Edit existing schema (see Use case 1). Data of already created annotations will be transformed to the shape of the updated schema. New fields of annotations in to_review and postponed state that are linked to extracted fields types will be filled by AI Engine, if available. New fields for already exported or deleted annotations (also purged, exporting and failed_export) will be filled with empty or default values.

Use case 4 - Adding new field to schema, only for newly imported documents

• Situation: User is extending a production schema by adding a new field. However, with the intention that the user does not want to see the newly added field on previously created annotations.
• Recommendation: Create a new schema object (POST) and link it to the queue. Annotation data of previously created annotations will be preserved according to the original schema. This approach is recommended if there is an organizational need to keep different field sets before and after the schema update.

Use case 5 - Deleting schema field, even for already imported documents.

• Situation: User is changing a production schema by removing a field that was used previously. However, user would like to see all annotations (to_review, postponed, exported, deleted, etc. states) in the look of the newly extended schema. There is no need to see the original fields in already exported annotations.
• Recommendation: Edit existing schema (see Use case 1).

Use case 6 - Deleting schema field, only for newly imported documents

• Situation: User is changing a production schema by removing a field that was used previously. However, with the intention that the user will still be able to see the removed fields on previously created annotations.
• Recommendation: Create a new schema object (see Use case 4). Annotation data of previously created annotations will be preserved according to the original schema. This approach is recommended if there is an organizational need to retrieve the data in the original state.

Preserving data on schema change

In order to transfer annotation field values properly during the schema update, a datapoint's category and schema_id must be preserved.

Supported operations that preserve fields values are:

• adding a new datapoint (filled from AI Engine, if available)
• reordering datapoints on the same level
• moving datapoints from section to another section
• moving datapoints to and from a tuple
• reordering datapoints inside a tuple
• making datapoint a multivalue (original datapoint is the only value in a new multivalue container)
• making datapoint non-multivalue (only first datapoint value is preserved)

Extracted field types

AI engine currently automatically extracts the following fields at the all endpoint, subject to ongoing expansion.

Identifiers

Example of a schema with different identifiers:

[
  {
    "category": "section",
    "children": [
      {
        "category": "datapoint",
        "constraints": {
          "required": false
        },
        "default_value": null,
        "id": "document_id",
        "label": "Invoice number",
        "rir_field_names": [
          "document_id"
        ],
        "type": "string"
      },
      {
        "category": "datapoint",
        "constraints": {
          "required": false
        },
        "default_value": null,
        "format": "D/M/YYYY",
        "id": "date_issue",
        "label": "Issue date",
        "rir_field_names": [
          "date_issue"
        ],
        "type": "date"
      },
      {
        "category": "datapoint",
        "constraints": {
          "required": false
        },
        "default_value": null,
        "id": "terms",
        "label": "Terms",
        "rir_field_names": [
          "terms"
        ],
        "type": "string"
      }
    ],
    "icon": null,
    "id": "invoice_info_section",
    "label": "Basic information"
  }
]

Document attributes

Amounts

Typical relations (may depend on local laws):

amount_total = amount_total_base + amount_total_tax
amount_rounding = amount_total - round(amount_total)
amount_due = amount_total - amount_paid + amount_rounding

All amounts are in the main currency of the invoice (as identified in the currency response field). Amounts in other currencies are generally excluded.

Tables

At the moment, the AI engine automatically extracts 2 types of tables. In order to pick one of the possible choices, set rir_field_names attribute on multivalue.

Tax details

Example of a tax details table:

{
  "category": "section",
  "children": [
    {
      "category": "multivalue",
      "children": {
        "category": "tuple",
        "children": [
          {
            "category": "datapoint",
            "constraints": {
              "required": false
            },
            "default_value": null,
            "format": "# ##0.#",
            "id": "vat_detail_rate",
            "label": "VAT rate",
            "rir_field_names": [
              "tax_detail_rate"
            ],
            "type": "number",
            "width": 15
          },
          ...
        ],
        "id": "vat_detail",
        "label": "VAT detail"
      },
      "default_value": null,
      "id": "vat_details",
      "label": "VAT details",
      "max_occurrences": null,
      "min_occurrences": null,
      "rir_field_names": [
        "tax_details"
      ]
    }
  ],
  "icon": null,
  "id": "amounts_section",
  "label": "Amounts section"
}

Tax details table and breakdown by tax rates.

Line items

Example of a line items table:

{
  "category": "section",
  "children": [
    {
      "category": "multivalue",
      "children": {
        "category": "tuple",
        "children": [
          {
            "category": "datapoint",
            "constraints": {
              "required": true
            },
            "default_value": null,
            "id": "item_desc",
            "label": "Description",
            "rir_field_names": [
              "table_column_description"
            ],
            "type": "string",
            "stretch": true
          },
          {
            "category": "datapoint",
            "constraints": {
              "required": false
            },
            "default_value": null,
            "format": "# ##0.#",
            "id": "item_quantity",
            "label": "Quantity",
            "rir_field_names": [
              "table_column_quantity"
            ],
            "type": "number",
            "width": 15
          },
          {
            "category": "datapoint",
            "constraints": {
              "required": false
            },
            "default_value": null,
            "format": "# ##0.#",
            "id": "item_amount_total",
            "label": "Price w tax",
            "rir_field_names": [
              "table_column_amount_total"
            ],
            "type": "number"
          }
        ],
        "id": "line_item",
        "label": "Line item",
        "rir_field_names": []
      },
      "default_value": null,
      "id": "line_items",
      "label": "Line item",
      "max_occurrences": null,
      "min_occurrences": null,
      "rir_field_names": [
        "line_items"
      ]
    }
  ],
  "icon": null,
  "id": "line_items_section",
  "label": "Line items"
}

AI engine currently automatically extracts line item table content and recognizes row and column types as detailed below. Invoice line items come in a wide variety of different shapes and forms. The current implementation can deal with (or learn) most layouts, with borders or not, different spacings, header rows, etc. We currently make two further assumptions:

• The table generally follows a grid structure - that is, columns and rows may be represented as rectangle spans. In practice, this means that we may currently cut off text that overlaps from one cell to the next column. We are also not optimizing for table rows that are wrapped to multiple physical lines.
• The table contains just a flat structure of line items, without subsection headers, nested tables, etc.

We plan to gradually remove both assumptions in the future.

Annotation Lifecycle

When a document is submitted to Rossum within a given queue, an annotation object is assigned to it. An annotation goes through a variety of states as it is processed, and eventually exported.

This diagram shows exact flow between the annotation states whole working with the UI.

Usage report

In order to obtain an overview of the Rossum usage, you can download Csv file with basic Rossum statistics.

The statistics contains following attributes:

• Username (may be empty in case document was not modified by any user)
• Workspace name
• Queue name
• User url
• Queue url
• Workspace url
• Imported: count of all documents that were imported during the time period
• Confirmed: count of all documents that were confirmed during the time period
• Rejected: count of all documents that were rejected during the time period
• Rejected automatically: count of all documents that were automatically rejected during the time period
• Rejected manually: count of all documents that were manually rejected during the time period
• Deleted: count of documents that were deleted during the time period
• Exported: count of documents that were successfully exported during the time period
• Net time: total time spent by a user validating the successfully exported documents

Download usage statistics (January 2019).

curl -H 'Authorization: Bearer db313f24f5738c8e04635e036ec8a45cdd6d6b03' \
  'https://<example>.rossum.app/api/annotations/usage_report?from=2019-01-01&to=2019-01-31'

Csv file (csv) may be downloaded from https://<example>.rossum.app/api/v1/annotations/usage_report?format=csv.

You may specify date range using from and to parameters (inclusive). If not specified, a report for last 12 months is generated.

Request

POST /v1/annotations/usage_report

{
  "filter": {
    "users": [
      "https://<example>.rossum.app/api/v1/users/173"
    ],
    "queues": [
      "https://<example>.rossum.app/api/v1/queues/8199"
    ],
    "begin_date": "2019-12-01",
    "end_date": "2020-01-31"
  },
  "exported_on_time_threshold_s": 86400,
  "group_by": [
    "user",
    "workspace",
    "queue",
    "month"
  ]
}

Response

Status: 200

{
  "series": [
    {
      "begin_date": "2019-12-01",
      "end_date": "2020-01-01",
      "queue": "https://<example>.rossum.app/api/v1/queues/8199",
      "workspace": "https://<example>.rossum.app/api/v1/workspaces/7540",
      "values": {
        "imported_count": 2,
        "confirmed_count": 6,
        "rejected_count": 2,
        "rejected_automatically_count": 1,
        "rejected_manually_count": 1,
        "deleted_count": null,
        "exported_count": null,
        "turnaround_avg_s": null,
        "corrections_per_document_avg": null,
        "exported_on_time_count": null,
        "exported_late_count": null,
        "time_per_document_avg_s": null,
        "time_per_document_active_avg_s": null,
        "time_and_corrections_per_field": []
      }
    },
    {
      "begin_date": "2020-01-01",
      "end_date": "2020-02-01",
      "queue": "https://<example>.rossum.app/api/v1/queues/8199",
      "workspace": "https://<example>.rossum.app/api/v1/workspaces/7540",
      "user": "https://<example>.rossum.app/api/v1/users/173",
      "values": {
        "imported_count": null,
        "confirmed_count": 6,
        "rejected_count": 3,
        "rejected_automatically_count": 2,
        "rejected_manually_count": 1,
        "deleted_count": 2,
        "exported_count": 2,
        "turnaround_avg_s": 1341000,
        "corrections_per_document_avg": 1.0,
        "exported_on_time_count": 1,
        "exported_late_count": 1,
        "time_per_document_avg_s": 70.0,
        "time_per_document_active_avg_s": 50.0,
        "time_and_corrections_per_field": [
          {
            "schema_id": "date_due",
            "label": "Date due",
            "total_count": 1,
            "corrected_ratio": 0.0,
            "time_spent_avg_s": 0.0
          },
          ...
        ]
      }
    },
    ...
  ],
  "totals": {
    "imported_count": 7,
    "confirmed_count": 6,
    "rejected_count": 5,
    "rejected_automatically_count": 3,
    "rejected_manually_count": 2,
    "deleted_count": 2,
    "exported_count": 3,
    "turnaround_avg_s": 894000,
    "corrections_per_document_avg": 1.0,
    "exported_on_time_count": 2,
    "exported_late_count": 1,
    "time_per_document_avg_s": 70.0,
    "time_per_document_active_avg_s": 50.0
  }
}

The response consists of two parts: totalsand series.

Totals

Totals contain summary information for the whole period (between begin_date and end_date).

Series

Series contain information grouped by fields defined in group_by. The data (see above) are wrapped in values object, and accompanied by the values of attributes that were used for grouping.

In addition to the totals data, series contain time_and_corrections_per_field list that provides detailed data about statistics on each field.

Series details

The detail object contains statistics grouped per field (schema_id).

*Corrected ratio is calculated based on human corrections. If any kind of automation (Hook, Webhook, etc) is ran on the datapoints, even after a human correction took a place, the corrected_ration will not be calculated -> Is set to 0.

Extensions

The Rossum platform may be extended via third-party, externally running services or custom functions. These extensions are registered to receive callbacks from the Rossum platform on various occasions and allow to modify the platform behavior. Currently we support these callback extensions: Webhooks, Serverless Functions, and Connectors.

Webhooks and connectors require a third-party service accessible through a HTTP endpoint. This may incur additional operational and implementation costs. User-defined serverless functions, on the contrary, are executed within Rossum platform and no additional setup is necessary. They share the interface (input and output data format, error handling) with webhooks.

See the Building Your Own Extension set of guides in Rossum's developer portal for an introduction to Rossum extensions.

Webhook Extension

The webhook component is the most flexible extension. It covers all the most frequent use cases:

• displaying messages to users in validation screen,
• applying custom business rules to check, change, or autofill missing values,
• reacting to document status change in your workflow,
• sending reviewed data to an external systems.

Implement a webhook

Webhooks are designed to be implemented using a push-model using common HTTPS protocol. When an event is triggered, the webhook endpoint is called with a relevant request payload. The webhook must be deployed with a public IP address so that the Rossum platform can call its endpoints; for testing, a middleware like ngrok or serveo may come useful.

Webhook vs. Connector

Webhook extensions are similar to connectors, but they are more flexible and easier to use. A webhook is notified when a defined type of webhook event occurs for a related queue.

Advantages of webhooks over connectors:

• There may be multiple webhooks defined for a single queue
• No hard-coded endpoint names (/validate, /save)
• Robust retry mechanism in case of webhook failure
• If webhooks are connected via the run_after parameter, the results from the predecessor webhook are passed to its successor

Webhooks are defined using a hook object of type webhook. For a description how to create and manage hooks, see the Hook API.

Webhook Events

Example data sent for annotation_status event to the hook.config.url when status of the annotation changes

{
  "request_id": "ae7bc8dd-73bd-489b-a3d2-f5514b209591",
  "timestamp": "2020-01-01T00:00:00.000000Z",
  "base_url": "https://<example>.rossum.app",
  "rossum_authorization_token": "1024873d424a007d8eebff7b3684d283abdf7d0d",
  "hook": "https://<example>.rossum.app/api/v1/hooks/789",
  "settings": {
    "example_target_service_type": "SFTP",
    "example_target_hostname": "sftp.elis.rossum.ai"
  },
  "secrets": {
    "username": "my-rossum-importer",
    "password": "secret-importer-user-password"
  },
  "action": "changed",
  "event": "annotation_status",
  "annotation": {
    "document": "https://<example>.rossum.app/api/v1/documents/314621",
    "id": 314521,
    "queue": "https://<example>.rossum.app/api/v1/queues/8236",
    "schema": "https://<example>.rossum.app/api/v1/schemas/223",
    "pages": [
      "https://<example>.rossum.app/api/v1/pages/551518"
    ],
    "creator": "https://<example>.rossum.app/api/v1/users/1",
    "modifier": null,
    "assigned_at": null,
    "created_at": "2021-04-26T10:08:03.856648Z",
    "confirmed_at": null,
    "deleted_at": null,
    "exported_at": null,
    "export_failed_at": null,
    "modified_at": null,
    "purged_at": null,
    "rejected_at": null,
    "confirmed_by": null,
    "deleted_by": null,
    "exported_by": null,
    "purged_by": null,
    "rejected_by": null,
    "status": "to_review",
    "previous_status": "importing",
    "rir_poll_id": "54f6b91cfb751289e71ddf12",
    "messages": null,
    "url": "https://<example>.rossum.app/api/v1/annotations/314521",
    "content": "https://<example>.rossum.app/api/v1/annotations/314521/content",
    "time_spent": 0,
    "metadata": {},
    "organization": "https://<example>.rossum.app/api/v1/organizations/1"
  },
  "document": {
    "id": 314621,
    "url": "https://<example>.rossum.app/api/v1/documents/314621",
    "s3_name": "272c2f41ae84a4f19a422cb432a490bb",
    "mime_type": "application/pdf",
    "arrived_at": "2019-02-06T23:04:00.933658Z",
    "original_file_name": "test_invoice_1.pdf",
    "content": "https://<example>.rossum.app/api/v1/documents/314621/content",
    "metadata": {}
  }
}

Example data sent for annotation_content event to the hook.config.url when user updates a value in UI

{
  "request_id": "ae7bc8dd-73bd-489b-a3d2-f5214b209591",
  "timestamp": "2020-01-01T00:00:00.000000Z",
  "base_url": "https://<example>.rossum.app",
  "rossum_authorization_token": "1024873d424a007d8eebff7b3684d283abdf7d0d",
  "hook": "https://<example>.rossum.app/api/v1/hooks/781",
  "settings": {
    "example_target_hostname": "sftp.elis.rossum.ai"
  },
  "secrets": {
    "password": "secret-importer-user-password"
  },
  "action": "updated",
  "event": "annotation_content",
  "annotation": {
    "document": "https://<example>.rossum.app/api/v1/documents/314621",
    "id": 314521,
    "queue": "https://<example>.rossum.app/api/v1/queues/8236",
    "schema": "https://<example>.rossum.app/api/v1/schemas/223",
    "pages": [
      "https://<example>.rossum.app/api/v1/pages/551518"
    ],
    "creator": "https://<example>.rossum.app/api/v1/users/1",
    "modifier": null,
    "assigned_at": null,
    "created_at": "2021-04-26T10:08:03.856648Z",
    "confirmed_at": null,
    "deleted_at": null,
    "exported_at": null,
    "export_failed_at": null,
    "modified_at": null,
    "purged_at": null,
    "rejected_at": null,
    "confirmed_by": null,
    "deleted_by": null,
    "exported_by": null,
    "purged_by": null,
    "rejected_by": null,
    "status": "to_review",
    "previous_status": "importing",
    "rir_poll_id": "54f6b91cfb751289e71ddf12",
    "messages": null,
    "url": "https://<example>.rossum.app/api/v1/annotations/314521",
    "organization": "https://<example>.rossum.app/api/v1/organizations/1",
    "content": [
      {
        "id": 1123123,
        "url": "https://<example>.rossum.app/api/v1/annotations/314521/content/1123123",
        "schema_id": "basic_info",
        "category": "section",
        "children": [
          {
            "id": 20456864,
            "url": "https://<example>.rossum.app/api/v1/annotations/1/content/20456864",
            "content": {
              "value": "18 492.48",
              "normalized_value": "18492.48",
              "page": 2,
              ...
            },
            "category": "datapoint",
            "schema_id": "number",
            "validation_sources": [
              "checks",
              "score"
            ],
            "time_spent": 0
          }
        ]
      }
    ],
    "time_spent": 0,
    "metadata": {}
  },
  "document": {
    "id": 314621,
    "url": "https://<example>.rossum.app/api/v1/documents/314621",
    "s3_name": "272c2f41ae84a4f19a422cb432a490bb",
    "mime_type": "application/pdf",
    "arrived_at": "2019-02-06T23:04:00.933658Z",
    "original_file_name": "test_invoice_1.pdf",
    "content": "https://<example>.rossum.app/api/v1/documents/314621/content",
    "metadata": {}
  },
  "updated_datapoints": [11213211, 11213212]
}

Example of a response for annotation_content hook

{
  "messages": [
    {
      "content": "Invalid invoice number format",
      "id": 197467,
      "type": "error"
    }
  ],
  "operations": [
    {
      "op": "replace",
      "id": 198143,
      "value": {
        "content": {
          "value": "John",
          "position": [103, 110, 121, 122],
          "page": 1
        },
        "hidden": false,
        "options": [],
        "validation_sources": ["human"]
      }
    },
    {
      "op": "remove",
      "id": 884061
    },
    {
      "op": "add",
      "id": 884060,
      "value": [
        {
          "schema_id": "item_description",
          "content": {
            "page": 1,
            "position": [162, 852, 371, 875],
            "value": "Bottle"
          }
        }
      ]
    }
  ]
}

Example data sent for email event to the hook.config.url when email is received by Rossum mail server

{
  "request_id": "ae7bc8dd-73bd-489b-a3d2-f5214b209591",
  "timestamp": "2020-01-01T00:00:00.000000Z",
  "base_url": "https://<example>.rossum.app",
  "rossum_authorization_token": "1024873d424a007d8eebff7b3684d283abdf7d0d",
  "hook": "https://<example>.rossum.app/api/v1/hooks/781",
  "settings": {
    "example_target_hostname": "sftp.elis.rossum.ai"
  },
  "secrets": {
    "password": "secret-importer-user-password"
  },
  "action": "received",
  "event": "email",
  "email": "https://<example>.rossum.app/api/v1/emails/987",
  "queue": "https://<example>.rossum.app/api/v1/queues/41",
  "files": [
    {
      "id": "1",
      "filename": "image.png",
      "mime_type": "image/png",
      "n_pages": 1,
      "height_px": 100.0,
      "width_px": 150.0,
      "document": "https://<example>.rossum.app/api/v1/documents/427"
    },
    {
      "id": "2",
      "filename": "MS word.docx",
      "mime_type": "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
      "n_pages": 1,
      "height_px": null,
      "width_px": null,
      "document": "https://<example>.rossum.app/api/v1/documents/428"
    },
    {
      "id": "3",
      "filename": "A4 pdf.pdf",
      "mime_type": "application/pdf",
      "n_pages": 3,
      "height_px": 3510.0,
      "width_px": 2480.0,
      "document": "https://<example>.rossum.app/api/v1/documents/429"
    },
    {
      "id": "4",
      "filename": "unknown_file",
      "mime_type": "text/xml",
      "n_pages": 1,
      "height_px": null,
      "width_px": null,
      "document": "https://<example>.rossum.app/api/v1/documents/430"
    }
  ],
  "headers": {
    "from": "test@example.com",
    "to": "east-west-trading-co-a34f3a@<example>.rossum.app",
    "reply-to": "support@example.com",
    "subject": "Some subject",
    "date": "Mon, 04 May 2020 11:01:32 +0200",
    "message-id": "15909e7e68e4b5f56fd78a3b4263c4765df6cc4d",
    "authentication-results": "example.com;\n    dmarc=pass d=example.com"
  },
  "body": {
    "body_text_plain": "Some body",
    "body_text_html": "<div dir=\"ltr\">Some body</div>"
  }
}

Example of a response for email hook

{
  "files": [
    {
      "id": "3",
      "values": [
        {
          "id": "email:invoice_id",
          "value": "INV001234"
        },
        {
          "id": "email:customer_name",
          "value": "John Doe"
        }
      ]
    }
  ]
}

Example data sent for invocation.scheduled event and action

{
  "request_id": "ae7bc8dd-73bd-489b-a3d2-f5514b209591",
  "timestamp": "2020-01-01T00:00:00.000000Z",
  "base_url": "https://<example>.rossum.app",
  "rossum_authorization_token": "1024873d424a007d8eebff7b3684d283abdf7d0d",
  "hook": "https://<example>.rossum.app/api/v1/hooks/789",
  "settings": {
    "example_target_service_type": "SFTP",
    "example_target_hostname": "sftp.elis.rossum.ai"
  },
  "secrets": {
    "username": "my-rossum-importer",
    "password": "secret-importer-user-password"
  },
  "action": "scheduled",
  "event": "invocation"
}

Example data sent for upload event to the hook.config.url when documents are uploaded (either through API or as an Email attachment)

{
  "request_id": "ae7bc8dd-73bd-489b-a3d2-f5214b209591",
  "timestamp": "2020-01-01T00:00:00.000000Z",
  "base_url": "https://<example>.rossum.app",
  "rossum_authorization_token": "1024873d424a007d8eebff7b3684d283abdf7d0d",
  "hook": "https://<example>.rossum.app/api/v1/hooks/781",
  "settings": {},
  "secrets": {},
  "action": "created",
  "event": "upload",
  "email": "https://<example>.rossum.app/api/v1/emails/987",
  "upload": "https://<example>.rossum.app/api/v1/uploads/2046",
  "metadata": {},
  "files": [
    {
      "document": "https://<example>.rossum.app/api/v1/documents/427",
      "prevent_importing": false,
      "values": [],
      "queue": "https://<example>.rossum.app/api/v1/queues/41",
      "annotation": null
    },
    {
      "document": "https://<example>.rossum.app/api/v1/documents/428",
      "prevent_importing": true,
      "values": [],
      "queue": "https://<example>.rossum.app/api/v1/queues/41",
      "annotation": "https://<example>.rossum.app/api/v1/annotations/1638"
    }
  ],
  "documents": [
    {
      "id": 427,
      "url": "https://<example>.rossum.app/api/v1/documents/427",
      "mime_type": "application/pdf",
      ...
    },
    {
      "id": 428,
      "url": "https://<example>.rossum.app/api/v1/documents/428",
      "mime_type": "application/json",
      ...
    }
  ]
}

Example of a response for document hook

{
  "files": [
    {
      "document": "https://<example>.rossum.app/api/v1/documents/427",
      "prevent_importing": false
    },
    {
      "document": "https://<example>.rossum.app/api/v1/documents/428",
      "prevent_importing": true
    },
    {
      "document": "https://<example>.rossum.app/api/v1/documents/429",
    },
    {
      "document": "https://<example>.rossum.app/api/v1/documents/430",
    }
  ]
}

Webhook events specify when the hook should be notified. They can be defined as following:

• either as whole event containing all supported actions for its type (for example annotation_status)
• or as separately named actions for specified event (for example annotation_status.changed)

Supported events and their actions

(*) May also contain other optional attributes - read more in this section.

• For each webhook call there is a 30 seconds timeout by default (this applies to all events and actions). It can be modified in config with attribute timeout_s (min=0, max=60, only for non-interactive webhooks).
• When annotation_content.export action fails, annotation is switched to the failed_export state.
• When response from webhook on annotation_content.export contains a message of type error, the annotation is switched to the failed_export state.
• In case a non-interactive webhook call fails (check the configuration of retry_on_any_non_2xx attribute of the webhook to see what statuses this includes), it is retried within 30 seconds by default. There are up to 5 attempts performed. This number can be modified in config with attribute retry_count (min=0, max=4, only for non-interactive webhooks).
• For a non-interactive webhook call with the resulting HTTP status 202 (asynchronous result), the response Location header provided url is polled the same number of times as the webhook url itself till it receives a 201 status code response of which the body is taken as the hook call result.
• The updated_datapoints list is never empty for annotation_content.updated only triggered by interactive date changes actions.
• The updated_datapoints list is always empty for the annotation_content.export action.
• The updated_datapoints list is empty for the annotation_content.initialize action if run_after=[], but it can have data from its predecessor if chained via run_after.
• The updated_datapoints list may also be empty for annotation_content.user_update in case of an action triggered interactively by a user, but with no data changes (e.g. after opening validation screen or eventually at its confirmation issued by the Rossum UI).

Webhook Events Occurrence Diagram

To show an overview of the Hook events and when they are happening, this diagram was created.

Hooks common attributes

Annotation status event data format

annotation_status event contains following additional event specific attributes.

^* Attribute is only included in the request when specified in hook.sideload. Please note that sideloading of modifier object from different organization is not supported and that sideloading can decrease performance. See also annotation sideloading section.

Example data sent to hook with sideloaded queue objects

{
  "request_id": "ae7bc8dd-73bd-489b-a3d2-f5214b209591",
  "timestamp": "2020-01-01T00:00:00.000000Z",
  "base_url": "https://<example>.rossum.app",
  "hook": "https://<example>.rossum.app/api/v1/hooks/781",
  "action": "changed",
  "event": "annotation_status",
  ...,
  "queues": [
    {
      "id": 8198,
      "name": "Received invoices",
      "url": "https://<example>.rossum.app/api/v1/queues/8198",
      ...,
      "metadata": {},
      "use_confirmed_state": false,
      "settings": {}
    }
  ]
}

Annotation content event data format

annotation_content event contains following additional event specific attributes.

^* Attribute is only included in the request when specified in hook.sideload. Please note that sideloading of modifier object from different organization is not supported and that sideloading can decrease performance. See also annotation sideloading section.

^** If the run_after attribute chains the hooks, the updated_datapoints will contain a list of all datapoint ids that were updated by any of the predecessive hooks. Moreover, in case of add operation on a multivalue table, the updated_datapoints will contain the id of the multivalue, the id of the new tuple datapoints and the id of all the newly created cell datapoints.

Annotation content event response format

All of the annotation_content events expect a JSON object with the following optional lists in the response: messages and operations

The message object contains attributes:

For example, you may use error for fatals like a missing required field, whereas info is suitable to decorate a supplier company id with its name as looked up in the suppliers database.

The operations object describes operation to be performed on the annotation data (replace, add, remove). Format of the operations key is the same as for bulk update of annotations, please refer to the annotation data API for complete description.

Parsable error response format

It's possible to use the same format even with non-2XX response codes. In this type of response, operations are not considered.

Example of a parsable error response

{
  "messages": [
    {
      "id": "all",
      "type": "error",
      "content": "custom error message to be displayed in the UI"
    }
  ]
}

initialize event of annotation_content action additionally accepts list of automation_blockers objects. This allows for manual creation of automation blockers of type extension and therefore stops the automation without the need to create an error message.

The automation_blockers object contains attributes

Example of a response for annotation_content.initialize hook creating automation blockers

{
  "messages": [...],
  "operations": [...],
  "automation_blockers": [
    {
      "id": 1357,
      "content": "Unregistered vendor"
    },
    {
      "content": "PO not found in the master data!"
    }
  ]
}

Email received event data format

email event contains following additional event specific attributes.

The files object contains attributes:

The headers object contains the same values as are available for initialization of values in email_header:<id> (namely: from, to, reply-to, subject,message-id,date`).

The body object contains the body_text_plain and body_text_html.

Email received event response format

All of the email events expect a JSON object with the following lists in the response: files, additional_files, extracted_original_sender

The files object contains attributes:

The values object consists of the following:

This is useful for filtering out unwanted files by some measures that are not available in Rossum by default.

The additional_files object contains attributes:

The extracted_original_sender object looks as follows:

This is useful for updating the email address field on email object with a new sender name and email address.

Upload created event data format

upload event contains following additional event specific attributes.

The files object contains attributes:

The values object consists of the following:

Upload created event response format

All of the upload events expect a JSON object with the files object list in the response.

The files object contains attributes:

Validating payloads from Rossum

Example of hook receiver, which verifies the validity of Rossum request

import hashlib
import hmac

from flask import Flask, request, abort

app = Flask(__name__)

SECRET_KEY = "<Your secret key stored in hook.config.secret>"  # never store this in code

@app.route("/test_hook", methods=["POST"])
def test_hook():
    digest = hmac.new(SECRET_KEY.encode(), request.data, hashlib.sha1).hexdigest()
    try:
        prefix, signature = request.headers["X-Elis-Signature"].split("=")
    except ValueError:
        abort(401, "Incorrect header format")

    if not (prefix == "sha1" and hmac.compare_digest(signature, digest)):
        abort(401, "Authorization failed.")
    return

For authorization of payloads, the shared secret method is used. When a secret token is set in hook.config.secret, Rossum uses it to create a hash signature with each payload. This hash signature is passed along with each request in the headers as X-Elis-Signature.

The goal is to compute a hash using hook.config.secret and the request body, and ensure that the signature produced by Rossum is the same. Rossum uses HMAC SHA1 signature.

Webhook requests may be autenticated using a client SSL certificate, see Hook API for reference.

Access to Rossum API

You can access Rossum API from the Webhook. Each execution gets unique API key. The key is valid for 10 minutes or until Rossum receives a response from the Webhook. You can set token_lifetime_s up to 2 hours to keep the token valid longer. The API key and the environment's base URL are passed to webhooks as a first-level attributes rossum_authorization_token and base_url within the webhook payload.

Serverless Function Extension

Serverless functions allows to extend Rossum functionality without setup and maintenance of additional services.

Webhooks and Serverless functions share a basic setup: input and output data format and error handling. They are both configured using a hook API object.

Unlike webhooks, serverless functions do not send the event and action notifications to a specific URL. Instead, the function's code snippet is executed within the Rossum platform. See function API description for details about how to setup a serverless function and connect it to the queue.

Supported events and their actions