Gini Health API Documentation v2.0

Introduction

Gini provides the information extraction system for analyzing documents for health domain, such as doctor's invoices. The system is capable of extracting fields like the document sender or the amount to pay as well as many other types of specific information from various invoice formats.

The API supports PDF, GIF, JPEG, PNG, and TIFF documents.

The information extraction starts when the document is sent to the extraction system. There it first gets verified and then classified as being native or scanned.

There is a difference between native and scanned PDF files. Native PDFs are created using Microsoft Word, Excel, Illustrator or other software that generates PDF files from source code. Scanned PDFs are created by scanning devices from the actual paper documents.

The native PDF documents already contain this information in the document source code and are processed accordingly. However, the scanned documents do not have the source code and therefore do not directly provide the information that can be easily read and understood by the system. Therefore, the extraction system has to apply Optical Character Recognition (OCR) and various computer vision techniques to obtain the document contents.

Once the layout and the textual contents become available for the uploaded document, the system starts extracting document semantic information such as the document sender (name, address) and meta information such as the document type (invoice, contract).

It might be so that the system is unable to extract the information correctly. This could most likely happen due to OCR errors caused by poor quality of the scanned document, incomplete textual data or quite specific document design format. In such cases it is still possible to correct the extractions by manually selecting the correct amount to pay on the document and submitting it back to the API. The extraction system will receive the feedback and help us to improve its self-learning algorithms over time.

If you have any questions about the Gini Health API and the functionality it provides, please contact us via api@gini.net.

Getting started

Welcome! In order to process your first document with the Gini Health API, you will have to perform the following easy steps:

1. register your application
2. obtain an access token
3. upload a document
4. check the document status information
5. retrieve the extractions
6. send feedback

For general information about the Gini Health API, see overview.

Register Your Application

Before you can use the Gini Health API in your application, you need a valid client ID and a client secret. If you don't have the client ID and the client secret already, please contact your sales representative.

Obtain an Access Token

obtain an access token

curl -v -X POST --data-urlencode 'username=random@example.org'
        --data-urlencode 'password=geheim'
        -H 'Content-Type: application/x-www-form-urlencoded'
        -H 'Accept: application/json'
        -u 'client-id:client-secret'
        'https://user.gini.net/oauth/token?grant_type=password'

the JSON response will look similar to

{
  "access_token":"6c470ffa-abf1-41aa-b866-cd3be0ee84f4",
  "token_type":"bearer",
  "expires_in":3599
}

6c470ffa-abf1-41aa-b866-cd3be0ee84f4 is the access token which can be used for API requests.

All requests to the Gini Health API are made on behalf of the user authorized by the access token. For now, let's assume that you've already created an anonymous user. If not, for the details on how to do so please read Direct Communication from Client Devices to the Gini Health API

In order to get an access token for the Gini account, run the example command on the right (don't forget to replace random@example.org with your username and geheim with your password as well as client-id with your client ID and client-secret with your client secret).

If your client is configured, you will also receive a refresh token in the token api response. With the received refresh token, you can get a new access token by calling token endpoint with refresh_token grant_type.

obtain an access token from refresh token

curl -v -X POST  --data-urlencode 'grant_type=refresh_token'
    --data-urlencode 'refresh_token=<refresh_token_received_from_token_api>' 
    -H 'Content-Type: application/x-www-form-urlencoded' 
    -H 'Accept: application/json' 
    -u "client-id:client-secret" 
    'https://user.gini.net/oauth/token'

Upload a Document

upload a document

curl -v -X POST --data-binary '@/path/to/your/document.pdf'
     -H 'Accept: application/vnd.gini.v2+json'
     -H 'Authorization: BEARER b6c470ffa-abf1-41aa-b866-cd3be0ee84f'
     'https://health-api.gini.net/documents'

Now that you have the access token, you can upload your first document by sending an API request. The request must contain the corresponding Gini API version number. For example for our first document, we will use Gini Health API version v2. The command on the right will send a request against the corresponding version of the API.

the response (in case the document was Accepted)

HTTP/1.1 201 Created
X-Request-Id: 7b5a7f79-ae7c-4040-b6cf-25cde58ad937
Location: https://health-api.gini.net/documents/b4bd3e80-7bd1-11e4-95ab-000000000000
Content-Type: application/vnd.gini.v2+json

If the file was accepted by the Gini Health API (i.e. its file format is supported), the extraction system automatically starts to process the document and responses with the HTTP status code 201 as well as the document location URL.

Check the Document Status Information

check the document status information

curl -v -H 'Accept: application/vnd.gini.v2+json'
        -H 'Authorization: BEARER b6c470ffa-abf1-41aa-b866-cd3be0ee84f'
  'https://health-api.gini.net/documents/b4bd3e80-7bd1-11e4-95ab-000000000000'

the response body will look similar to

{
  "_links": {
    "processed": "https:\/\/health-api.gini.net\/documents\/b4bd3e80-7bd1-11e4-95ab-000000000000\/processed",
    "layout": "https:\/\/health-api.gini.net\/documents\/b4bd3e80-7bd1-11e4-95ab-000000000000\/layout",
    "extractions": "https:\/\/health-api.gini.net\/documents\/b4bd3e80-7bd1-11e4-95ab-000000000000\/extractions",
    "document": "https:\/\/health-api.gini.net\/documents\/b4bd3e80-7bd1-11e4-95ab-000000000000"
  },
  "sourceClassification": "NATIVE",
  "origin": "UPLOAD",
  "progress": "PENDING",
  "creationDate": 1417710133864,
  "pages": [
    {
      "images": {
        "1280x1810": "https:\/\/health-api.gini.net\/documents\/b4bd3e80-7bd1-11e4-95ab-000000000000\/pages\/1\/1280x1810",
        "750x900": "https:\/\/health-api.gini.net\/documents\/b4bd3e80-7bd1-11e4-95ab-000000000000\/pages\/1\/750x900"
      },
      "pageNumber": 1
    }
  ],
  "pageCount": 1,
  "name": "Document",
  "id": "b4bd3e80-7bd1lll-11e4-95ab-000000000000"
}

The document processing takes a bit of time and in order to get the extractions, you need to check the status of the processed document periodically. The status can have the value PENDING, which means that the document is being analyzed, and COMPLETED, which means that the document analysis is complete and the extractions are ready for retrieval. Check the current document status by sending a GET request to the URL that you received when the document was uploaded. Once the status changes to COMPLETED, the extractions are ready and you can retrieve them.

Retrieve the Extractions

retrieve the extractions

curl -v -H 'Accept: application/vnd.gini.v2+json'
    -H 'Authorization: BEARER b6c470ffa-abf1-41aa-b866-cd3be0ee84f'
    'https://health-api.gini.net/documents/b4bd3e80-7bd1-11e4-95ab-000000000000/extractions'

The document extractions represent various document contents that the extraction system was able to understand and retrieve. In order to get all the extractions, send a request to the right (notice the API version v2).

example response

{
  "extractions": {
    "docType": {
      "value": "Invoice",
      "entity": "doctype",
      "confidence": 0.923
    },
    "amountToPay": {
      "candidates": "amounts",
      "box": {
        "page": 1,
        "height": 9.0,
        "width": 30.870000000000005,
        "left": 524.13,
        "top": 357.89
      },
      "value": "12.00:EUR",
      "entity": "amount"
    },
    "customerId": {
      "candidates": "customerIds",
      "box": {
        "page": 1,
        "height": 7.0,
        "width": 31.139999999999986,
        "left": 470.0,
        "top": 152.89
      },
      "confidence": 0.821,
      "value": "20980000",
      "entity": "customerid"
    },
    "invoiceId": {
      "candidates": "invoiceIds",
      "box": {
        "page": 1,
        "height": 7.0,
        "width": 38.920000000000016,
        "left": 470.0,
        "top": 143.89
      },
      "confidence": 0.971,
      "value": "3113805926",
      "entity": "invoiceid"
    },
    "senderName": {
      "candidates": "senderNames",
      "box": {
        "page": 1,
        "height": 7.0,
        "width": 52.56000000000001,
        "left": 41.87,
        "top": 88.84
      },
      "value": "Deutsche Post AG",
      "entity": "companyname"
    }
  },
  "compoundExtractions": {
  },
  "candidates": {
    "amounts": [
      {
        "box": {
          "page": 1,
          "height": 9.0,
          "width": 30.870000000000005,
          "left": 524.13,
          "top": 357.89
        },
        "value": "12.00:EUR",
        "entity": "amount"
      },
      {
        "box": {
          "page": 1,
          "height": 12.0,
          "width": 40.89999999999998,
          "left": 138.02,
          "top": 413.09
        },
        "value": "12.00:EUR",
        "entity": "amount"
      }
   ],
    "senderNames": [
      {
        "box": {
          "page": 1,
          "height": 7.0,
          "width": 52.56000000000001,
          "left": 41.87,
          "top": 88.84
        },
        "value": "Deutsche Post AG",
        "entity": "companyname"
      }
    ],
    "customerIds": [
      {
        "box": {
          "page": 1,
          "height": 7.0,
          "width": 31.139999999999986,
          "left": 470.0,
          "top": 152.89
        },
        "value": "20980000",
        "entity": "customerid"
      }
    ],
    "invoiceIds": [
      {
        "box": {
          "page": 1,
          "height": 7.0,
          "width": 38.920000000000016,
          "left": 470.0,
          "top": 143.89
        },
        "value": "3113805926",
        "entity": "invoiceid"
      }
    ]
  }
}

The returned object contains specific extractions (a value with some specific semantic property), compound extractions (a group of values with some specific semantic property) as well as candidates (a list of values for some semantic property).

The example response (shortened, on the right) is an invoice (see docType) issued by Deutsche Post AG with invoice number 3113805926 (see invoiceId). The receiver of the invoice has to pay 12€ (see amountToPay).

Send Feedback and Get Even Better Extractions Next Time

Feedback is an API request containing the correct extractions that you can send us in order to improve the future extraction accuracy of the system. In fact your application should always send at least some feedback. The more complete and qualitative the feedback is, the sooner the extraction system learns what is correct and what's not. Feedback is critical to us and important to you because there is no other way for us know in realtime whether the extraction system is delivering the best possible quality for your application.

In order to inform the system the extraction was correct or incorrect, send back the correct value in the feedback request. It is important that it should be the value exactly as it appears on the actual document (not calculated or inferred). Once the feedback is received it gets compared to the extracted value and the result is used futher in reports and is included into a self-learning mechanism of the Gini extraction system.

Getting Client Configurations

If you want to retrieve client configurations, you can do this by sending a GET request to /configurations endpoint. You should be sending user access token as a bearer token.

get client configurations from Health API

GET /configurations
Host: health-api.gini.net
Authorization: BEARER c796535e-32e4-11eb-b966-e30e07dee3dc
Accept: application/json

response

{
  "clientId": "your-client-id",
  "communicationTone": "FORMAL",
  "ingredientBrandType": "INVISIBLE"
}

Response

Overview of the Gini Health API

This section provides general information about the Gini Health API. If you want a step-by-step guide how to upload your first document and retrieve its semantic content, have a look at the getting started guide.

IPv6 Compatibility

IPv6 compatibility example

    $ host health-api.gini.net
    health-api.gini.net has address 46.245.182.123
    health-api.gini.net has IPv6 address 2a00:14e0:600:1500:d0c5::7

    $ host user.gini.net
    user.gini.net has address 46.245.182.124
    user.gini.net has IPv6 address 2a00:14e0:600:1500:d0c5::2

Gini Health API and User Center are accessible from legacy IPv4 and IPv6 networks. The protocol precedence depends on your operating system and configuration if both protocols are enabled.

Media Types

the media types consumed and produced by the Gini Health API look like this

    application/vnd.gini.<version>+json

Custom media types are used in the API to let the consumers choose the version of the data format they wish to receive. This is done by adding one or more of the following media types to the Accept header when a request is made. media types are specific to resources, allowing them to change independently and supporting formats that other resources don't.

API Versions

Currently there is one stable version of the Gini Health API. Future versions can be requested using a specific Accept header. This is primarily for testing new extractions but may affect other parts of the API as well.

Version 2 (v2)

v2 media type

    Accept: application/vnd.gini.v2+json

Gini Health API v2 is stable and will remain backwards compatible. Please contact us via api@gini.net if you have any problems.

Developers are strongly encouraged to explicitly specify the required version of the Gini Health API using the HTTP/1.1 Accept header (see the example) because by default the requests are treated as requests to version 1 (v1) of the API.

Authentication

Only authenticated users are allowed to make API requests. The Gini API uses the OAuth 2.0 protocol with bearer tokens for authentication.

In order to use the API in your application, you first have to register your application with Gini. Afterwards your application should request an access token from the Gini Authorization Server and use it to access the Gini Health API.

Security

The Gini Health API is only accessible over HTTPS. Please make sure that your application validates the relevant X.509 certificates (e.g. common name matches hostname, issuing CA is trusted, etc.).

Client Errors

HTTP response codes

The API uses idiomatic HTTP status codes to indicate if a request was successful or not and whether it should be repeated.

Error Entity

error entity response

{
  "message": "Validation of the request entity failed",
  "requestId": "8896f9dc-260d-4133-9848-c54e5715270f"
}

In case of an error, the Gini Health API always returns a JSON object with further information about the occurred error. The JSON object consists of the following properties:

Managing Anonymous Gini Accounts

In order to achieve best results, the Gini Health API must be able to track the requests down to individual users for the following reasons:

• Users might have their own opinions about the document type or the correctness of the certain value.
• The feedback correctness is decided based on the number of similar values submitted by the users.

Gini offers various ways to perform requests on behalf of the individual users without requiring physical interaction. Depending on your use case and your product's architecture, the following API authentication methods are available:

• trusted

  Your application communicates with the Gini Health API via a common backend that runs on a trusted device. Each request states which user the request is made for via the application's user identifier. No account management is required.

• untrusted

  On the first API usage, your application creates an anonymous Gini user in the background and uses those account credentials for subsequent requests. This works best for (mobile) applications where the app communicates directly with the Gini Health API on an untrusted device.

Communicating with the Gini Health API via Backend / Gateway

request the list of user1's documents

curl -v -H 'Accept: application/vnd.gini.v2+json'
    -u 'client-id:client-secret'
    -H 'X-User-Identifier: user1'
    https://health-api.gini.net/documents

This authentication scheme is based on HTTP Basic Authentication. Your application needs to use HTTP Basic Authentication to authenticate itself with the Gini Health API. Additionally, another header called X-User-Identifier is sent together with the Authorization header in one request. This header is used by the API to identify individual users. Your application is free to choose whatever value it wants for the header, as long as the following constraints are met:

• Each user's identifier must be unique.
• Once set for a user, the identifier must remain the same.

Direct Communication between Client Devices and the Gini Health API

Gini offers the User Center API (UC API) to work with the Gini users. Here is a quick step-by-step guide that outlines how to create and use a new anonymous Gini account. Each step links to the corresponding section in the UC API where you can read more details about it.

1. obtain the client token
2. create a new user
3. log in as a new user
4. make API requests with the access token

Authenticate the Client

obtain the client token

curl -v -H 'Accept: application/json'
    -u 'client-id:client-secret'
    'https://user.gini.net/oauth/token?grant_type=client_credentials'

the successful response will have HTTP status 200 and the client access token 1eb7ca49-d99f-40cb-b86d-8dd689ca2345 will be returned

{
  "access_token":"1eb7ca49-d99f-40cb-b86d-8dd689ca2345",
  "token_type":"bearer","expires_in":43199,"scope":"read"
}

Before you are able to use the UC API, you need to obtain a client access token. The client access token authorizes your client (i.e. your application) against the UC API and allows you to create a new user.

At this point it is assumed that you already have the client ID client-id and the client secret client-secret. These will authorize your client (with HTTP Basic Authentication) to obtain the client access token, see the example on the right.

For more details see the corresponding UC API section.

Create a New User

create a new user

curl -v -X POST --data '{"email":"random@example.org", "password":"geheim"}'
    -H 'Content-Type: application/json'
    -H 'Accept: application/json'
    -H 'Authorization: BEARER 1eb7ca49-d99f-40cb-b86d-8dd689ca2345'
    'https://user.gini.net/api/users'

the above command creates a new user random@example.org with password geheim. If the creation was successful, the HTTP response has status 201 and contains the Location header pointing to the new user. Your client is now allowed to create a new user authorized by the client access token.

Once the client access token is successfully obtained, it's time to create a new user. To do so we require two more values: a username and a password. The username must be represented by a correct email address whose domain part is easily linkable to your application. For example, if your company is called Example Inc. then app.example.org would be a good domain name to use for your application's user accounts.

For more details see the corresponding UC API section.

Authenticate on behalf of a New User

login as a new user

curl -v -X POST --data-urlencode 'username=random@example.org'
    --data-urlencode 'password=geheim'
    -H 'Content-Type: application/x-www-form-urlencoded'
    -H 'Accept: application/json' -u 'client-id:client-secret'
    'https://user.gini.net/oauth/token?grant_type=password'

After the new user is created, you can log in. Note that log in request uses HTTP Basic Authentication with the client ID as a username and with the client secret as a password. It does not require a client access token. The request response will contain an access token that can be used to make API requests on behalf of the new user.

For more details see the corresponding UC API section.

Make API Requests with the Access Token

use the access token you obtained to make API requests

GET /documents HTTP/1.1
Host: health-api.gini.net
Authorization: BEARER 760822cb-2dec-4275-8da8-fa8f5680e8d4
Accept: application/vnd.gini.v2+json
Connection: close

In order to make API requests, send the access token as a bearer token in the Authorization request header.

Documents

As the key aspect of the Gini Health API is to provide information extraction for analyzing documents, the API is mainly built around the concept of documents. A document can be any written representation of information such as invoices, reminders, contracts and so on.

The main idea is that you submit a document in the form of an electronic file to Gini. After the document has been analyzed by Gini you can get the information that is extracted from the document by querying the API.

The following documentation explains those actions in more detail.

Submitting Files

documents can be submitted by doing a POST request to the /documents resource.

    POST /documents

In order to extract document information, the document source file must be first submitted to Gini.

Submitting documents is as easy as sending a POST request to the /documents resource path. After successful submission the location of the new document is returned in the Location header.

The Gini Health API currently supports two different variants of uploads, one optimized for web applications running in a web browser and the other for all other types of clients.

The first variant optimized for web applications expects the documents to be uploaded using a multipart/form-data encoding method.

The second variant for all other clients simply uses the request body (independent of the request Content-Type) as the document.

Supported File Formats

Gini currently supports document files in PDF, GIF (non-animated), PNG, JPEG, TIFF as well as plain text formats. You can use native documents (PDF only) as well as scanned document (all other supported formats).

Note that there are certain limitations though:

• document file size must be less than 10 MiB
• PDF files must not have any security restrictions such as password protection
• scanned documents should have a resolution of at least 300 dpi in order for the OCR to return optimal results
• plain text documents have to be encoded in UTF-8 and the source size must be smaller than 512 KiB
• only the first 10 pages of a document are processed
• only document contents in the German language is recognized sufficiently well

The above applies both to single page documents as well as to each page in a multi-page document.

Document Type Hints

In many cases the type of a document is known to the client application. If you provide the doctype parameter with a valid type, Gini can optimize the processing of the document in various ways.

Document Uploading Schemes

The Gini API allows you to upload a document as a single file or in parts, page by page.

Upload a Single File Document

This is the standard way of uploading a document to the Gini extraction system. A PDF document can contain single or multiple pages. JPEG, PNG documents are also accepted. When it is uploaded, it is processed by the system normally and without any adjustments regarding its structure.

Request

upload a document

variant for web applications running in a web browser with access token:

curl -H 'Authorization: BEARER <token>'
    --form 'file=@file.pdf'
    -H 'Accept: application/vnd.gini.v2+json'
    -i https://health-api.gini.net/documents

variant for all other types of applications:

curl -H 'Authorization: BEARER <token>'
    --data-binary '@file.pdf'
    -H 'Accept: application/vnd.gini.v2+json'
    -i https://health-api.gini.net/documents?filename=file.pdf

or with X-User-identifier (see how to setup X-User-identifier):

curl -H 'X-User-Identifier: user1'
    --form 'file=@file.pdf'
    -H 'Accept: application/vnd.gini.v2+json'
    -u 'client-id:client-secret'
    -i https://health-api.gini.net/documents

Headers

Requesting Query Parameters

If the upload is performed without multipart/form-data you can optionally provide a file name for the submitted document with a query parameter:

Body

Only in case of Content-Type: multipart/form-data (applications running in a web browser):

Response

Headers

Errors

Upload a Document Page by Page

Partial upload should be performed in two steps: a partial documents upload and a composite document upload. Keep in mind that you must complete Step 1 first before moving to Step 2!

Step 1 (Upload Each Page as a Partial Document)

Pages that are part of the document are referred to as partial documents. If you want to upload a page (or a page picture) that belongs to the document, your request header should additionally include Content-Type field with application/vnd.gini.v2.partial+png value or application/vnd.gini.v2.partial+pdf in case of PDF page.

Request

upload a partial document

variant for web applications running in a web browser with access token:

curl -H 'Authorization: BEARER <token>'
    --form 'file=@file.JPEG'
    -H 'Accept: application/vnd.gini.v2+json'
    -H 'Content-Type: application/vnd.gini.v2.partial+png'
    -i https://health-api.gini.net/documents

variant for other types of applications with access token:

curl -H 'Authorization: BEARER <token>'
    --data-binary '@file.JPEG'
    -H 'Accept: application/vnd.gini.v2+json'
    -H 'Content-Type: application/vnd.gini.v2.partial+png'
    -i https://health-api.gini.net/documents?filename=file.JPEG

or with X-User-identifier (see how to setup X-User-identifier):

curl -H 'X-User-Identifier: user1'
    --form 'file=@file.JPEG'
    -H 'Accept: application/vnd.gini.v2+json'
    -H 'Content-Type: application/vnd.gini.v2.partial+png'
    -u 'client-id:client-secret'
    -i https://health-api.gini.net/documents

In order to upload a page picture or a partial document, specify a different content type:

Headers

Request Query Parameters

Body

File contents of the document.

Response

Headers

Errors

Step 2 (Upload JSON as a Composite Document)

After successfully uploading all pages as partial documents, you should announce their locations to the extraction system. This is done by uploading a composite document which is a simple JSON file with corresponding locations of partial documents.

Request

upload a composite document

variant for web applications running in a web browser with access token:

curl -H 'Authorization: BEARER <token>'
    -H 'Accept: application/vnd.gini.v2+json'
    -H 'Content-Type: application/vnd.gini.v2.composite+json'
    -X POST -d'{...}'
    -i https://health-api.gini.net/documents

or

curl -H 'Authorization: BEARER <token>'
    --data-binary '@data.json'
    -H 'Accept: application/vnd.gini.v2+json'
    -H 'Content-Type: application/vnd.gini.v2.composite+json'
    -i https://health-api.gini.net/documents

or with X-User-identifier (see how to setup X-User-identifier):

curl -H 'X-User-Identifier: user1'
    -H 'Accept: application/vnd.gini.v2+json'
    -H 'Content-Type: application/vnd.gini.v2.composite+json'
    -u 'client-id:client-secret'
    -X POST - d'{...}'
    -i https://health-api.gini.net/documents

with post body of

{
  "partialDocuments": [
    {
      "rotationDelta": 0,
      "document": "localtion of parital doc 1"
    },
    {
      "rotationDelta": 0,
      "document": "location of partial doc 2"
    },
    ...
  ]
}

location in form of https://health-api.gini.net/documents/e8606210-56ed-11ea-b823-b351b84ae4b3

In order to upload a composite document which aggregates one or multiple partial documents, a different content type needs to be specified.

Headers

Request Query Parameters

If the upload is performed without multipart/form-data you can optionally provide a file name for the submitted document with a query parameter:

Body

Raw bytes of the composite json.

Response

Headers

Errors

Checking Processing Status and Getting Document Information

document information can be retrieved by sending a GET request to the document URI.

    GET /documents/{id}

Once the document is submitted and processed you can check its processing status by examining the document information. It can be retrieved with a GET request containing the document URI. When the document has been processed you can retrieve its extractions and layout.

Request

get document processing status

curl -H 'Authorization: BEARER <token>'
    -X GET -H 'Accept: application/vnd.gini.v2+json'
    -i https://health-api.gini.net/documents/c292af40-d06a-11e2-9a2f-000000000000

Headers

Response

request response

{
  "id": "626626a0-749f-11e2-bfd6-000000000000",
  "creationDate": 1360623867402,
  "name": "scanned.jpg",
  "progress": "COMPLETED",
  "origin": "UPLOAD",
  "sourceClassification": "SCANNED",
  "pageCount": 1,
  "_links": {
    "extractions": "https://health-api.gini.net/documents/626626a0-749f-11e2-bfd6-000000000000/extractions",
    "layout": "https://health-api.gini.net/documents/626626a0-749f-11e2-bfd6-000000000000/layout",
    "document": "https://health-api.gini.net/documents/626626a0-749f-11e2-bfd6-000000000000",
    "processed": "https://health-api.gini.net/documents/626626a0-749f-11e2-bfd6-000000000000/processed"
  }
}

Headers

Body (application/vnd.gini.v2+json)

Errors

Retrieving Extractions

extractions can be retrieved by performing a GET request with the extractions URI:

    GET /documents/{id}/extractions

Once the document is processed, the document extractions become available for retrieval. See document extractions for more details.

Request

get extractions

curl -H 'Authorization: BEARER <token>'
    -X GET -H 'Accept: application/vnd.gini.v2+json'
    -i https://health-api.gini.net/documents/c292af40-d06a-11e2-9a2f-000000000000/extractions

Headers

Response

example response

{
   "extractions": {
       "amountToPay": {
           "box": {
               "height": 9.0,
               "left": 516.0,
               "page": 1,
               "top": 588.0,
               "width": 42.0
           },
           "confidence": 0.715,
           "entity": "amount",
           "value": "24.99:EUR",
           "candidates": "amounts"
       }
     },
     "candidates": {
       "amounts": [
         {
             "box": {
                 "height": 9.0,
                 "left": 516.0,
                 "page": 1,
                 "top": 588.0,
                 "width": 42.0
             },
             "entity": "amount",
             "value": "24.99:EUR"
         },
         {
             "box": {
                 "height": 9.0,
                 "left": 241.0,
                 "page": 1,
                 "top": 588.0,
                 "width": 42.0
             },
             "entity": "amount",
             "value": "21.0:EUR"
         }
       ]
       ...
   }
}

Headers

Body (application/vnd.gini.v2+json)

A detailed explanation of the response format can be found in document extractions section.

Errors

Submitting Feedback on Extractions

You should always submit the feedback on extractions in order to help the system improve its extraction quality.

Gini employs various machine learning techniques in order to learn from feedback automatically. Therefore, it is equally important for Gini to receive both feedback on correct and on incorrect extractions. There are currently two ways to submit the feedback. The first and the most common one is to submit the complete feedback in one request. This is the easiest way if your frontend (application) displays the extractions on a screen in an editable form. A user can modify the extractions before pressing the confirmation button. Another way (a rare use case) is where the final approvement signal (button click) is not possible. In such case you can send the feedback on one label per request.

There are three different types of feedback:

• positive feedback: (Our preferred type) the extraction was correct and confirmed by the user without modification.
• complementary feedback: The extraction system extracted nothing, e.g. the response does not contain the requested label. The user manually entered the correct value.
• negative feedback: The extraction was incomplete or erroneous. The user manually corrected the extraction.

Please see detailed examples next.

Submitting Feedback on Extractions

submitting feedback on extractions

    PUT /documents/{id}/extractions

    POST /documents/{id}/extractions

The Gini Health API allows you to submit the feedback on multiple extractions for a single document with a single request. It is strongly recommended that you submit your feedback in this way for two reasons. On the one hand, the total number of round trips is reduced to one and the feedback is handled internally as a batch. Therefore, the update is more efficient for multiple extractions compared to submitting the feedback with each separate request (see single feedback). On the other hand, Gini's machine learning training techniques can benefit from the feedback on multiple extractions since Gini will be aware of the fact that single parts of the submitted feedback belong together.

Request

Example

We show a more elaborated example here in order to explain different types of the feedback. The example scenario is as follows: the user uploads a document where the labels amountToPay, paymentReference, iban are extracted. Unfortunately the label paymentRecipient could not be extracted. The response to the extractions request is as follows:

{
    "candidates": {
    },
    "extractions": {
        "amountToPay": {
            "box": {
                "height": 8.0,
                "left": 545.0,
                "page": 1,
                "top": 586.0,
                "width": 17.0
            },
            "candidates": "amounts",
            "entity": "amount",
            "value": "5.60:EUR"
        },
        "iban": {
            "box": {
                "height": 7.0,
                "left": 447.0,
                "page": 1,
                "top": 746.0,
                "width": 100.0
            },
            "candidates": "ibans",
            "entity": "iban",
            "value": "DE68130300000017850360"
        },
        "paymentReference": {
            "entity": "reference",
            "value": "ReNr 123, KdNr 32"
        }
    },
    "compoundExtractions": {
        "taxItems": [
            {
              "taxRate": {
                "value": "19.0%",
                "entity": "text"
              },
              "taxAmount": {
                "value": "30.00:EUR",
                "entity": "amount"
              }
            }
        ]
    }
}

The user adds missing paymentRecipient value (complementary feedback) and corrects the paymentReference to "ReNr 1735, KdNr 37" (negative feedback). The iban, amountToPay, taxItems are correct (positive feedback). The document is not shown, so we can leave out the boxes. Then the resulting feedback request is as follows:

{
   "extractions": {
       "amountToPay": {
           "value": "5.60:EUR"
       },
       "iban": {
           "value": "DE68130300000017850360"
       },
       "paymentReference": {
           "value": "ReNr 1735, KdNr 37"
       },
       "paymentRecipient": {
           "value": "Zalando SE"
       }
   },
 "compoundExtractions": {
        "taxItems": [
            {
              "taxRate": {
                "value": "19.0%",
                "entity": "text"
              },
              "taxAmount": {
                "value": "30.00:EUR",
                "entity": "amount"
              }
            }
        ]
    }
}

Give feedback and correct or verify multiple specific labeled extraction patterns with a single PUT or POST request to the document extractions URI.

The labels must correspond to the names of the extraction types e.g. amountToPay. See available specific extractions for possible values.

Headers

Body

Response

Submitting Feedback on Invalid Extractions

submitting feedback on invalid extractions

    DELETE /documents/{id}/extractions/{label}

Request

In case an extraction was erroneously found (i.e. not present in the source document), you can delete it by issuing a DELETE request to the extraction URI:

Response

Retrieving Document Pages

retrieving document pages

    GET /documents/{id}/pages

The Gini Health API renders preview images of the document pages. In order to retrieve a list of pages for a document, issue a GET request to the pages sub-resource of the document.

Request

Path Parameters

retrieve document pages

curl -H 'Authorization: BEARER <token>'
    -X GET -H 'Accept: application/vnd.gini.v2+json'
    -i https://health-api.gini.net/documents/c292af40-d06a-11e2-9a2f-000000000000/pages

Headers

Response

the response will be a list of pages.

[
  {
    "images" : {
      "1280x1810" : "https://health-api.gini.net/documents/c292af40-d06a-11e2-9a2f-000000000000/pages/1/1280x1810",
      "750x900" : "https://health-api.gini.net/documents/c292af40-d06a-11e2-9a2f-000000000000/pages/1/750x900"
    },
    "pageNumber" : 1
  },
  {
    "pageNumber" : 2,
    "images" : {
      "1280x1810" : "https://health-api.gini.net/documents/c292af40-d06a-11e2-9a2f-000000000000/pages/2/1280x1810",
      "750x900" : "https://health-api.gini.net/documents/c292af40-d06a-11e2-9a2f-000000000000/pages/2/750x900"
    }
  }
]

Headers

Body

A page is an entity with the following fields:

Retrieving the Layout of a Document

The layout of the document describes the textual content of a document with positional information, based on the processed document.

Request

retrieving a layout of the document

    GET /documents/{id}/layout

Example

curl -H 'Authorization: BEARER <token>'
    -X GET -H 'Accept: application/vnd.gini.v2+json'
    -i https://health-api.gini.net/documents/c292af40-d06a-11e2-9a2f-000000000000/layout

The layout of the document can be retrieved by a GET request to the layout URI:

Headers

Response

layout example

{
  "pages": [
    {
      "number": 1,
      "sizeX": 595.3,
      "sizeY": 841.9,
      "textZones": [
        {
          "paragraphs": [
            {
              "l": 54.0,
              "t": 158.76,
              "w": 190.1,
              "h": 36.55000000000001,
              "lines": [
                {
                  "l": 54.0,
                  "t": 158.76,
                  "w": 190.1,
                  "h": 10.810000000000002,
                  "wds": [
                    {
                      "l": 54.0,
                      "t": 158.76,
                      "w": 18.129999999999995,
                      "h": 9.900000000000006,
                      "fontSize": 9.9,
                      "fontFamily": "Arial-BoldMT",
                      "bold":false,
                      "text": "Ihre"
                    },
                    {
                      "l": 74.86,
                      "t": 158.76,
                      "w": 83.91000000000001,
                      "h": 9.900000000000006,
                      "fontSize": 9.9,
                      "fontFamily": "Arial-BoldMT",
                      "bold":false,
                      "text": "Vorgangsnummer"
                    },
                    {
                      "l": 158.76,
                      "t": 158.76,
                      "w": 3.3000000000000114,
                      "h": 9.900000000000006,
                      "fontSize": 9.9,
                      "fontFamily": "Arial-BoldMT",
                      "bold":false,
                      "text": ":"
                    },
                    [...]
                  ]
                },
                [...]
              ]
            }
          ]
        }
      ],
      "regions": [
        {
          "l": 20.0,
          "t": 240.1,
          "w": 190.0,
          "h": 150.3,
          "type": "RemittanceSlip"
        },
        [...]
      ]
    },
    [...]
  ]
}

Headers

Body (application/vnd.gini.v2+json)

Page Object

TextZone Object

Paragraph Object

Line Object

Word Object

Region Object

Errors

404 (Not Found) The requested layout is invalid.

Retrieving the Processed Document

Request

retrieve the processed document

    GET /documents/{id}/processed

Before Gini tries to extract the information, it preprocesses the document, performing page deskewing, homography transformation, etc. The processed document can be retrieved by a GET request:

Path parameters

Response

Headers

Body

The version of the uploaded document file after preprocessing (color corrected, deskewed) which has been used for all layout and semantic extractions. In case of native PDF documents it is identical to the original document file.

Errors

Deleting Documents

delete documents

    DELETE /documents/{id}

If you want to delete a document you can do this by sending a DELETE request to the document URI. When the document is deleted all associated resources (extractions, layout) will be deleted as well.

Request

delete request

curl -H 'Authorization: BEARER <token>'
    -X DELETE -i https://health-api.gini.net/documents/c292af40-d06a-11e2-9a2f-000000000000

Delete the document by sending a DELETE request to the document URI.

Response

Headers

Errors

Getting a List of All Documents

get a list of all documents

    GET /documents

In order to get the list of all documents, send a GET request to the /documents resource. The response will contain a paginated list of all documents.

Request Query Parameters

example request

curl -H 'Authorization: BEARER <token>'
    -H 'Accept: application/vnd.gini.v2+json'
    -X GET -i https://health-api.gini.net/documents?limit=50

Response

example response

{
  "documents": [
    {...},
    {...},
    ...
  ]
}

The response will contain a paginated list of documents.

Headers

Body

The response entity has the following fields:

Document Extractions

Structured documents contain a lot of valuable information. For instance, invoices or remittance slips contain amounts to be paid, bank data, receiver, sender, address etc. Doctor prescriptions contain drug amounts, names and descriptions as well as other sensitive information.

The Gini extraction system is able to extract this information and provide it in a structured form accessible through its Health API. From now on we shall refer to such data as the document extractions. Some extractions are shared between certain documents e.g. amount to pay, sender, date and others are quite unique e.g. medical treatment, time of receipt issue, invoice id.

The extraction system however does a little bit more than just information extraction. For example, certain invoices contain blobs of text with due date information without a specific date value or tag but an explanation of when the invoice is supposed to be paid. The Gini system is capable of inferring this data and converting it to the actual date value. We shall refer to this kind of information as specific extractions.

Additionally, Gini system groups various semantically related terms into compound extractions. For example, IBAN and BIC belong to the single compound bankData, tax rate and tax amount to taxItems.

Extractions

Extraction

{
  "entity": "date",
  "value": "2012-06-20",
  "box": { ... }
  "confidence": 0.997
}

An extraction contains an entity which describes a general semantic type of the extraction (e.g. a date, an address, an amount). The entity also determines the format of the value containing text information. There may be an optional box element describing the position of the extraction value on the document. We refer to it as the bounding box. In most cases the extractions without a bounding box are considered to be meta information such as doctype. Additionally, we provide the confidence of extraction correctness.

Specific Extractions

specific extractions

{
  "paymentDueDate": {
      "entity": "date",
      "value": "2012-06-20",
      "box": { ... },
      "candidates": "dates"
  }
}

A specific extraction assigns a semantic property to the extraction. It also has an additional candidates field:

Available Specific Extractions

Compound Extractions

Compound Extraction describe a group of extractions.

Available Compound Extractions

compound extractions example

{
 "compoundExtractions": {
     "taxItems": [
       {
         "taxRate": {
           "entity": "text",
           "value": "19.0 %"
         },
         "taxAmount": {
           "entity": "amount",
           "value": "57.21:EUR",
           "box": {...
           }
         }
       }
     ]
   }
}

Extraction Candidates

Extraction candidates represent a list of suggestions for an appropriate extraction.

Available Extraction Candidates

extraction candidates

{
    "dates": [
      {"entity": "date","value": "2012-06-20","box": { ... } },
      {"entity": "date","value": "2012-05-10","box": { ... } },
      ...
    ]
}

Extraction Entities

Available extraction entities list (follow each link for a detailed description):

• amount
• bankaccount
• banknumber
• bic
• city
• companyname
• companynameaddition
• companyregisterid
• currency
• customerid
• date
• doctype
• documentdomain
• email
• iban
• invoiceid
• numeric
• paymentstate
• phonenumber
• poboxnumber
• recipient
• reference
• street
• taxnumber
• text
• time
• url
• vat
• zipcode

Bounding Box

Bounding Box

{
    "box": {
      "page": 2,
      "left": 483.0,
      "top": 450.0,
      "width": 51.0,
      "height": 9.0
    }
}

A bounding box creates a direct relation between an extraction and a document. The box describes the page and the position where the extraction originates from.

Coordinate System

The origin of the coordinate system is adjusted to the upper left corner of the page. The coordinate system uses the DTP point as unit: 1 pt = 1 inch / 72 = 25.4 mm / 72 = 0.3528 mm.

Extraction Confidence

confidence example

{
    "entity": "recipient",
    "value": "Max Mustermann Musterstrasse 1 Musterstadt",
    "box": {
        "top": 379.0,
        "left": 68.0,
        "width": 244.0,
        "height": 10.0,
        "page": 1
    },
    "confidence": 0.955
}

We believe it is important to provide the information about how confident our system is of performed extractions. Therefore, we implemented a mechanism that allows to predict the confidence of document extractions. The confidence prediction algorithm estimates the chance of delivering the correct extraction based on previous extractions and your feedback. For example, we introduced an additional JSON field confidence that is an optional part of each document extraction now.

Due to the nature of the algorithm and the amount of feedback we are receiving, the system cannot deliver a confidence value for every single extraction. Keep in mind that a portion of document extractions will not have confidence field. However, if the field exists we estimate it's reliability between 98%-100%. For example, if the system returns netAmount with "confidence": 0.95 there is very little chance that the extraction is incorrect and you can save resources on proofreading.

Entity Reference

amount

amount

{
    "entity": "amount",
    "value": "33.78:EUR",
    "box": {
        "page": 1,
        "left": 535.0,
        "top": 395.0,
        "width": 25.0,
        "height": 10.0
    }
}

Describes an amount of money with a specific currency in the format <Amount>:<Currency Code>, where <Amount> is a decimal number with "." as decimal separator and ":" as delimiter between <Amount> and <Currency Code>.

The currency code must be given according to the list specified in ISO 4217.

Format

Valid Feedback

<Number> <Currency Code/Symbol> (1-space-separation) 12,3 EUR; 12,4 USD; 12 € <Currency Code/Symbol> <Number> (1-space-separation) EUR 12.3; \$ 12.4

• If there is no <Number> in the string, it will be rejected.
• If there is no <Currency Code/Symbol>, it will be treated as default 'EUR' (default currency code).

bankaccount

bankaccount

{
    "entity": "bankaccount",
    "value": "1597880",
    "box": {
        "page": 1,
        "left": 506.0,
        "top": 777.0,
        "width": 53.0,
        "height": 6.0
    }
}

Describes a bank account number.

Format

Valid Feedback

If the string has less than 3 digits, it will be rejected.

banknumber

banknumber

{
    "entity": "banknumber",
    "value": "70250150",
    "box": {
        "page": 1,
        "left": 147.0,
        "top": 427.0,
        "width": 52.0,
        "height": 8.0
    }
}

Describes a bank number.

Format

Valid Feedback

bic

Describes a BIC number.

bic

{
    "entity": "bic",
    "value": "GENODEF1HH2",
    "box": {
        "page": 1,
        "left": 506.0,
        "top": 777.0,
        "width": 53.0,
        "height": 6.0
    }
}

Format

Valid Feedback

city

city

{
    "entity": "city",
    "value": "München",
    "box": {
        "page": 1,
        "left": 535.0,
        "top": 395.0,
        "width": 25.0,
        "height": 10.0
    }
}

Describes a city.

Format

companyname

companyname

{
    "entity": "companyname",
    "value": "Weinquelle Lühmann",
    "box": {
        "page": 1,
        "left": 535.0,
        "top": 395.0,
        "width": 25.0,
        "height": 10.0
    }
}

Describes a (sender) company name.

Format

Valid Feedback

A string with a single letter/digit character will be rejected.

companynameaddition

companynameaddition

{
    "entity": "companynameaddition",
    "value": "Kundenservice",
    "box": {
        "page": 1,
        "left": 535.0,
        "top": 395.0,
        "width": 25.0,
        "height": 10.0
    }
}

Describes a (sender) company name addition (e.g. Kundenservice).

Format

companyregisterid

companyregisterid

{
    "entity": "companyregisterid",
    "value": "HRB:108514:München",
    "box": {
        "page": 1,
        "left": 525.0,
        "top": 805.0,
        "width": 34.0,
        "height": 6.0
    }
}

Describes a German Register number in the format <Area of the Commercial Registry>:<Number>:<Office of the Registry> with ":" as a delimiter between the components.

Format

currency

currency

{
    "entity": "currency",
    "value": "EUR",
    "box": {
        "page": 1,
        "left": 535.0,
        "top": 395.0,
        "width": 25.0,
        "height": 10.0
    }
}

Describes the currency of the document.

The currency code must be given according to the list specified in ISO 4217.

Format

Valid Feedback

Euro currency symbol € Euro Currency name/code | EUR, EURO

Since only German documents are supported at the moment, the following strings are allowed: €, EUR, EURO

customerid

customerid

{
    "entity": "customerid",
    "value": "M500721563",
    "box": {
        "page": 1,
        "left": 317.0,
        "top": 123.0,
        "width": 158.0,
        "height": 8.0
    }
}

Describes a customer ID.

Format

Valid Feedback

date

date

{
    "entity": "date",
    "value": "2012-11-16",
    "box": {
        "page": 1,
        "left": 429.0,
        "top": 143.0,
        "width": 40.0,
        "height": 8.0
    }
}

Describes a date in the format <Year>-<Month>-<Day> with "-" as a delimiter between the date components.

Format

Valid Feedback

Document Types

doctype

{
    "entity": "doctype",
    "value": "Invoice"
}

Describes a document type. A list of supported document types:

• BankStatement
• Contract
• Invoice
• Receipt
• Reminder
• RemittanceSlip
• TravelExpenseReport
• Other

Format

Valid Feedback

documentdomain

documentdomain

{
    "entity": "documentdomain",
    "value": "TeleCommunication"
}

Describes a document domain. A list of supported values:

• TeleCommunication
• Other
• HealthInsurance
• Energy
• Travel

Format

Valid Feedback

email

email

{
    "entity": "email",
    "value": "info@t-online.de",
    "box": {
        "page": 1,
        "left": 189.0,
        "top": 820.0,
        "width": 73.0,
        "height": 7.0
    }
}

Describes an email in the format <Name>@<Domain> with "@" as a delimiter between email components.

Format

Valid Feedback

iban

iban

{
    "entity": "iban",
    "value": "DE74700500000000028273",
    "box": {
        "page": 1,
        "left": 425.0,
        "top": 770.0,
        "width": 83.0,
        "height": 6.0
    }
}

Describes an IBAN.

Format

Valid Feedback

Invalid IBAN will be rejected.

invoiceid

invoiceid

{
    "entity": "invoiceid",
    "value": "201210124056",
    "box": {
        "page": 1,
        "left": 429.0,
        "top": 133.0,
        "width": 53.0,
        "height": 8.0
    }
}

Describes an invoice ID as identifier.

Format

Valid Feedback

numeric

numeric

{
    "entity": "numeric",
    "value": "12.5",
    "box": {
        "page": 1,
        "left": 429.0,
        "top": 133.0,
        "width": 53.0,
        "height": 8.0
    }
}

Describes a numeric value (integer/float).

Format

Valid Feedback

paymentstate

paymentstate

{
    "entity": "paymentState",
    "value": "Paid"
}

Describes a payment state as one of the following values:

• Paid
• ToBePaid

Format

Valid Feedback

phonenumber

phonenumber

{
    "entity": "phonenumber",
    "value": "08923508270",
    "box": {
        "page": 1,
        "left": 425.0,
        "top": 770.0,
        "width": 83.0,
        "height": 6.0
    }
}

Describes a phone number in one of the two formats <CountryCode> <Number> with " " as a delimiter and <Number> without a country code. All punctuation marks (e.g. "/", "-"), spaces and "(0)" (e.g. +49(0)61957746361) are deleted.

Format

Valid Feedback

Brackets, spaces, leading '+', and '-' are allowed.

poboxnumber

poboxnumber

{
    "entity": "poboxnumber",
    "value": "22087",
    "box": {
        "page": 1,
        "left": 223.0,
        "top": 125.0,
        "width": 16.0,
        "height": 6.0
    }
}

Describes a post-office box.

Format

Valid Feedback

The keyword can be one of the following: Postfach, PF, Brieffach.

recipient

recipient

{
    "entity": "recipient",
    "value": "Max Mustermann Musterstrasse 1 Musterstadt",
    "box": {
        "top": 379.0,
        "left": 68.0,
        "width": 244.0,
        "height": 10.0,
        "page": 1
    }
}

Represents the recipient of a letter.

Format

reference

reference

{
    "entity": "reference",
    "value": "K19218331",
    "box": {
        "page": 1,
        "left": 535.0,
        "top": 395.0,
        "width": 25.0,
        "height": 10.0
    }
}

Describes a payment reference.

Format

Valid Feedback

A string with less than 5 non space characters will be rejected.

street

street

{
    "entity": "street",
    "value": "Emmy-Noether-Straße:2a",
    "box": {
        "page": 1,
        "left": 162.0,
        "top": 125.0,
        "width": 55.0,
        "height": 6.0
    }
}

Describes a street in the format <Street name>:<House number> with ":" as a delimiter between components. All abbreviations (e.g. "str.") are replaced with the German word "Straße".

Format

Valid Feedback

taxnumber

taxnumber

{
    "entity": "taxnumber",
    "value": "143/163/40289",
    "box": {
        "page": 1,
        "left": 501.0,
        "top": 812.0,
        "width": 58.0,
        "height": 6.0
    }
}

Describes a German tax number in the format <taxOfficeNumber>/<taxOfficeAreaNumber>/<personalNumber><checkDigit> with "/" as delimiter between the first 3 components.

Format

Valid Feedback

All kinds of delimiters that are common for tax numbers are allowed (e.g. '/', '-'). A string without delimiters is also allowed.

text

text

{
    "entity": "text",
    "value": "Aktenzeichen: K19218331",
    "box": {
        "page": 1,
        "left": 535.0,
        "top": 395.0,
        "width": 25.0,
        "height": 10.0
    }
}

Describes a plain text entity.

Format

Valid Feedback

Generally Text entity accepts all kinds of Text as feedback except for some specific fields which the extra rules are applied to.

time

time

{
    "entity": "time",
    "value": "12:13:14",
    "box": {
        "page": 1,
        "left": 429.0,
        "top": 143.0,
        "width": 40.0,
        "height": 8.0
    }
}

Describes a time in the format <hour>:<minute>:<second> with ":" as a delimiter between the time components.

Format

url

url

{
    "entity": "url",
    "value": "www.m-net.de",
    "box": {
        "page": 1,
        "left": 444.0,
        "top": 553.0,
        "width": 50.0,
        "height": 8.0
    }
}

Describes the host part of an URI as defined in RFC 3986. http:// is implicitly assumed as URI scheme.

Format

Valid Feedback

vat

vat

{
    "entity": "vat",
    "value": "DE188796931",
    "box": {
        "page": 1,
        "left": 453.0,
        "top": 812.0,
        "width": 43.0,
        "height": 6.0
    }
}

Describes a EU VAT number.

Format

Valid Feedback

Currently only VAT for 'DE' 'GB' 'FR' 'AT' allowed.

zipcode

zipcode

{
    "entity": "zipCode",
    "value": "18337",
    "box": {
        "page": 1,
        "left": 62.0,
        "top": 25.0,
        "width": 55.0,
        "height": 6.0
    }
}

Describes a ZIP code.

Format

Valid Feedback

User Center API

Gini's User Center offers an API to programmatically create new Gini accounts and to make API requests on behalf of the created user.

Client Authentication

All access to the User Center API requires client authentication. A client can authenticate itself with the Client Credentials Grant described in RFC 6749. In short, the client exchanges its client ID and client secret for an access token.

Request

get a client access token

curl -v -H 'Accept: application/json'
    -u 'client-id:secret'
    'https://user.gini.net/oauth/token?grant_type=client_credentials'

GET /oauth/token?grant_type=client_credentials HTTP/1.1
Authorization: Basic Y2xpZW50LWlkOnNlY3JldA==
Host: user.gini.net
Accept: application/json

example response

{
  "access_token":"74c1e7fe-e464-451f-a6eb-8f0998c46ff6","token_type":"bearer","expires_in":3599
}

In order to get a client access token, send a GET request to /oauth/token?grant_type=client_credentials. The request must contain a basic HTTP access authorization header with the client ID as a username and the client secret as a password.

The client can now use the returned access token to make requests to the User Center API by sending the token as a bearer token in the Authorization request header:

GET /api/users/c1e60c6b-a0a4-4d80-81eb-c1c6de729a0e HTTP/1.1
Host: user.gini.net
Authorization: BEARER 74c1e7fe-e464-451f-a6eb-8f0998c46ff6
Accept: application/json

Authenticating on behalf of a User

authenticating on behalf of a user

curl -v -X POST --data-urlencode
    'username=some_user@example.com'
    --data-urlencode 'password=supersecret'
    -H 'Content-Type: application/x-www-form-urlencoded'
    -H 'Accept: application/json'
    -u 'client-id:secret' 'https://user.gini.net/oauth/token?grant_type=password'

POST /oauth/token?grant_type=password HTTP/1.1
Authorization: Basic Y2xpZW50LWlkOnNlY3JldA==
Host: user.gini.net
Accept: application/json
Content-Type: application/x-www-form-urlencoded

username=some_user@example.com&password=supersecret

example response

{
  "access_token":"6c470ffa-abf1-41aa-b866-cd3be0ee84f4",
  "token_type":"bearer",
  "expires_in":3599
}

The returned access token can now be used to make requests to the Gini Health API on behalf of the user. To do so, send the access token as a bearer token in the Authorization request header:

GET /documents HTTP/1.1
Host: health-api.gini.net
Authorization: BEARER 6c470ffa-abf1-41aa-b866-cd3be0ee84f4
Accept: application/vnd.gini.v2+json
Connection: close

The Resource Owner Password Credentials Grant can be used to exchange a user's email address and a password with an access token. The access token can then be used to make requests to the Gini API on behalf of the user.

Request

Note that the client must authenticate itself using basic HTTP access authentication with its ID as a username and its secret as a password.

Creating a New User

creating a new user

curl -v -X POST --data '{"email":"some_user@example.com", "password":"supersecret"}'
    -H 'Content-Type: application/json'
    -H 'Accept: application/json'
    -H 'Authorization: BEARER 74c1e7fe-e464-451f-a6eb-8f0998c46ff6'
    'https://user.gini.net/api/users'

POST /api/users HTTP/1.1
Host: user.gini.net
Authorization: BEARER 74c1e7fe-e464-451f-a6eb-8f0998c46ff6
Content-Type: application/json

{"email":"some_user@example.com","password:"supersecret"}

example response

HTTP/1.1 201 Created
Location: https://user.gini.net/api/users/c1e60c6b-a0a4-4d80-81eb-c1c6de729a0e
Content-Length: 0

In order to create a new user, submit a POST request to /api/users.

Request

If the request entity was invalid (missing field(s), password < 6 characters etc.) or a user with that email address already exists, the API will respond with 400 Bad Request.

Retrieving User Information

retrieving user information

GET /api/users/88a28076-18e8-4275-b39c-eaacc240d406 HTTP/1.1
Host: user.gini.net
Authorization: BEARER 74c1e7fe-e464-451f-a6eb-8f0998c46ff6
Accept: application/json

Response

{
  "id":"88a28076-18e8-4275-b39c-eaacc240d406",
  "email":"some_user@example.com"
}

Information about a user can be retrieved with a GET request to /api/users/{userId}

Response

Changing a User's Password and/or Email

change a user's password and/or email

PUT /api/users/c1e60c6b-a0a4-4d80-81eb-c1c6de729a0e HTTP/1.1
Host: user.gini.net
Authorization: BEARER 74c1e7fe-e464-451f-a6eb-8f0998c46ff6
Content-Type: application/json

with

{"oldPassword":"supersecret","password:"anothersecret"}

or

{"oldEmail":"old@email.com","email:"my.new@email.com"}

or

{
 "oldPassword":"supersecret",
 "password":"anothersecret",
 "oldEmail":"old@email.com",
 "email":"my.new@email.com"}

A user's password and/or email can be changed with a PUT request to /api/users/{userId}. In order to update a user's password and/or email, the current password/email must be provided.

Request

oldPassword The user's current password. password | The password to which the user's password should be changed to. oldEmail | The user's current email. email | The email to which the user's email should be changed to.

Deleting a User

delete a user

DELETE /api/users/16aecc72-8032-4df6-9686-eaf4ec9532b8 HTTP/1.1
Host: user.gini.net
Authorization: BEARER 74c1e7fe-e464-451f-a6eb-8f0998c46ff6
Content-Type: application/json

An existing derived user can be deleted with a DELETE request to /api/users/{userId}. This also deletes all data associated with that user (e.g. access tokens, documents and extractions).

Deleting a Derived User

delete a derived user

DELETE /users/user1 HTTP/1.1
Host: health-api.gini.net
Authorization: BEARER 74c1e7fe-e464-451f-a6eb-8f0998c46ff6
Content-Type: application/json

An existing user can be deleted with a DELETE request to /users/{X-User-Identifier} on health api. users api on health-api can only be accessible by clients, not end users (i.e. Bearer token should be of type client not a resource owner). This also deletes all data associated with that user (e.g. access tokens, documents and extractions).

Troubleshooting

If you have trouble using the Gini Health API and you need to contact the support, there is some information you should always provide in order for us to help you quickly and efficiently.

X-Request-Id

The request id is generated for every request against the Gini Health API and tracked through the whole system. It is included in every response you receive from the Gini Health API as the HTTP header X-Request-Id. Please refer to it when you contact our support.

Document Id

The document id is generated for every accepted upload. It is included in the Location HTTP header which is part of the response to a successful upload. Please refer to the document id if you have questions related to the specific document upload.