Aller au contenu principal

Golem.ai Analyses API v2 (2.0.0)

Download OpenAPI specification:Download

This is a sample of the Golem.ai Documentation containing any necessary informations to post an analysis and get its result with the v2 API of Golem.ai.

Authentication

The Golem.ai API is secured by a set of API Keys, and all your API requests must be made over HTTPS and must be authenticated with these API Keys.

The API keys will be provided by Golem.ai. You will have two values: the "Secret Key" and the "App ID".

  • The "App ID" allows us to easily identify your integration, and is not sensitive information. You have to send it as a query parameter, with the name appId, so your URLs will end with something like ?appId=<YOUR_APP_ID>.
  • The "Secret Key" is the real authorization token, and so is sensitive data. You just have to use it as the value of the Authorization HTTP header.

Getting started

To use our API, you will need to create an analysis. Then, to retrieve the result, you can either do it the "push-based" way, with webhooks, or the "pull-based" way, with other HTTP REST calls.

Create an analysis

You will need to send your message with the /environment/{environmentId}/analyses endpoint. The endpoint's documentation contains all details on how to send your message.

Retrieve results with a webhook

This is the preferred way of retrieving the result: we send the result as soon as possible, and we know when we delivered the result for sure.

If you choose to integrate with this way, we will integrate the webhook in our configuration. When the analysis will be done, Golem.ai will do a HTTP POST request to an URL you defined. You can also define a pair of header name and value that we will send alongside the request, to protect your endpoint.

For more information on the webhook format, you will have more information on the /analysis/{analysisId}/result endpoint.

Retrieve results by HTTP REST call

By using the the /analysis/{analysisId}/result endpoint, you will have the same output you would have received by webhook.

Analyses

Create and access ICv2 analyses.

Create an analysis

Create an analysis in the environment provided in the path.

The inputs of an analysis

An analysis is composed of multiple inputs. For each input, you must specify:

  • the type of the input: is it the BODY (the main content)? An ATTACHMENT (a file)? Or another type for more information? (TICKET_TOPIC for example)
  • the content type of the input: is it a file or simply text.

To specify the inputs, you have to build the inputs JSON array. Here is an example with all kinds of inputs:

[
  {
    "type": "BODY",
    "contentType": "file",
    "file_key": "file_1"
  },
  // another possibility is to use a text input as the main content
  // but you should have only one BODY input
  {
    "type": "BODY",
    "contentType": "text",
    "text": "Main content to analyse",
    "name": "Main content" // This is optional, but recommended
  },
  // if you have attachments, you can specify them
  {
    "type": "ATTACHMENT",
    "contentType": "file",
    "file_key": "attachment_1"
  },
  {
    "type": "ATTACHMENT",
    "contentType": "file",
    "file_key": "attachment_2"
  },
  // if you have more information that golem must analyse.
  {
    "type": "TICKET_TOPIC",
    "contentType": "text",
    "text": "Ticket topic",
    "name": "TICKET_TOPIC" // This is optional, but recommended
  }
]

This inputs array must be set in the payload field of the request. The request must be a multipart/form-data request, and payload is mandatory to describe the analysis. It contains a JSON object, with the inputs array, but also other fields, namely:

  • metadata: a JSON object containing the metadata of the analysis. Metadata are data you might want to keep around on your analysis, for example to match it back to something on your end when you receive the result by webhook.
    • the inbox metadata is special: if you have multiple "inboxes" for your messages, you should set this field to the inbox of the message. It will open a lot of features in the Golem.ai console.
  • name: a string containing the name of the analysis. This is optional, and by default is set to the filename of the first BODY file. If that file has a non-descriptive name, you should set this field.
  • manualFinalStatusUpdate: a boolean indicating that the success or failure of the analysis must be confirmed by an external automation. If you're not sure if you need it, you don't need it.
  • inputs: the array of inputs described above.
Authorizations:
(Secret_KeyApp_ID)
path Parameters
environmentId
required
integer <int64>

ID of the environment where the analysis must be created

Request Body schema:

Content and settings for this analysis

file
string <binary>
manualFinalStatusUpdate
boolean
metadata
object

Metadata associated to the analysis. If you specify the inbox metadata, tools will be available to work with analysis coming from precises inboxes.

payload
string

A JSON Object encoded as a string which defines how to create an API.

  • inputs describes the inputs of the analysis. Usually, you don't touch this.
  • name allows overriding the name of the analysis. If not defined, it will use the filename of the BODY file
  • metadata defines the metadata associated to the analysis. Useful for integration purposes. If you specify the inbox metadata, tools will be available to work with analyses coming from precises inboxes.
files*
additional property
string <binary>

The files you want to upload. The name of the field in the request payload (e.g., file or file1) must be specified in the inputs field of the payload parameter.

Responses

Request samples

Content type
No sample

Response samples

Content type
application/json
{
  • "id": "7f8e8725-221d-4128-bdb4-c655d0884ca8"
}

Get the result of an an analysis

Get an analysis result according to a configured flow.

The result can be overridden by integrations, but unless explicitly told so, the result will contain the same payload sent to any webhook.

The payload is configured on Golem.ai side. If the output misses some information you see here but is absent from the result, it might be a misconfiguration.

Authorizations:
(Secret_KeyApp_ID)
path Parameters
analysisId
required
string

ID of the analysis

Responses

Response samples

Content type
application/json
Example

The analysis is still processing, the result is null

{
  • "status": "IN_PROGRESS",
  • "result": null
}

Feedback

This route allows a user to send feedback on an analysis. It uses the same payload as /analyses/{analysisId}/result which the user will need to modify to submit the correction. You can use feedbackURL in the resul's payload to send a feedback on the analysis you queried.

Authorizations:
(Secret_KeyApp_ID)
path Parameters
analysisId
required
string
Request Body schema: application/json
object (result)

Inside the "result" key

analysisId
string
filename
string
metadata
object
categories
Array of strings

The list of categories found for this message. Unless explicitly told so, will always be either an empty array or an array with one entry.

attachmentsCategories
object

A key-value object where keys are attachments' names and values are there categories. The same rules applies as for the categories field.

object

The extracted data. Usually, will contain the message and attachments keys, but can contain a more specific format if needed.

replyTemplate
string

The draft generated based on the analysis.

feedbackURL
string

Use this URL to send feedback on the analysis

Responses

Request samples

Content type
application/json
{
  • "result": {
    }
}