Document Parsing API - Getting Started Guide

This guide walks you through document parsing only with the Prestatech Document Engine API: authenticate, create a process, upload files, learn when parsing has finished, and optionally run consistency checks across the parsed documents. It does not cover the credit risk report — for that, see the Document Parsing + Credit Report guide.

Prerequisites

Before starting, you'll need:

1. Access to the API Portal at https://api-portal.prestatech.com/
2. A set up user account and active subscription. Consult with us, if you think you don't have any.
3. Your subscription credentials (client_id, client_secret, subscription_key)
4. OpenAPI specification for the Document Engine API

API Base URL

All API requests are made to: https://api.prestatech.com

📥 Prefer Postman? Download the client Postman collection — import it, set the collection's credential variables, and every endpoint in this guide is ready to run.

Overview

Everything is organised around a process — a container for one application or case. You upload documents into it, the platform parses them asynchronously and notifies you per file, and once the documents are parsed you can optionally run consistency checks across them.

The flow is:

1. Authenticate (Step 1).
2. Create a process to hold the case (Step 2).
3. Upload a file (Step 3) — parsing starts automatically, or on your explicit trigger.
4. Learn when parsing finished (Step 4) — via the "Doc Engine" webhook, or by reading the file by id.
5. Run consistency checks across the parsed documents (Step 5) — optional.

Sequence at a glance

sequenceDiagram
    autonumber
    participant C as Client Application
    participant API as Prestatech API
    participant WH as Client Webhook

    Note over C,API: Step 1 — Authentication
    C->>API: POST /auth/v1/oauth/token (client_id, client_secret)
    API-->>C: 200 OK (access_token)

    Note over C,API: Step 2 — Create a process
    C->>API: POST /start-process
    API-->>C: 200 OK (process_id)

    Note over C,API: Step 3 — Upload a file
    C->>API: POST /processes/{process_id}/files
    API-->>C: 200 OK (file_id, parsing_status)

    Note over C,API: Step 3 (option 2) — Start parsing manually
    C->>API: POST /processes/{process_id}/run-parsing
    API-->>C: 200 OK (file_ids, parsing started)

    Note over API,WH: Step 4a — Parsing webhook ("Doc Engine" callback, recommended)
    API-->>WH: POST {your Doc Engine callback url} (parsed file result)

    Note over C,API: Step 4b — Or read the file by id (on demand)
    C->>API: GET /processes/{process_id}/files/{file_id}
    API-->>C: 200 OK (parsing_status, parsing_result)

    Note over C,API: Step 5 — Run consistency checks (optional)
    C->>API: POST /processes/{process_id}/run-checks
    API-->>C: 200 OK (consistency check results)

Step 1: Authentication

Get Access Token

First, obtain an access token using your client credentials from the "Subscription" section in the API portal.

Request:

curl -X POST "https://api.prestatech.com/auth/v1/oauth/token" \
  -H "Content-Type: application/json" \
  -H "Ocp-Apim-Subscription-Key: YOUR_SUBSCRIPTION_KEY" \
  -d '{
    "client_id": "your-client-id",
    "client_secret": "your-client-secret"
  }'

Response:

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "refresh_token": null,
  "scope": "manage:live-prestatechopenapi manage:live",
  "expires_in": 86400,
  "token_type": "Bearer"
}

Save the access_token - you'll need it for all subsequent API calls.

Step 2: Create a Process

A process serves as a logical container for files related to a single application or case. This helps distinguish between different applications.

Request:

curl -X POST "https://api.prestatech.com/document-engine/v1/start-process" \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Ocp-Apim-Subscription-Key: YOUR_SUBSCRIPTION_KEY" \
  -H "Content-Type: application/json" \
  -d '{}'

The response contains a process_id — use it for every file you upload into this case.

Step 3: Upload a File

Upload a document into the process. Each upload returns a file_id and the current parsing_status.

Request:

curl -X POST "https://api.prestatech.com/document-engine/v1/processes/{process_id}/files" \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Ocp-Apim-Subscription-Key: YOUR_SUBSCRIPTION_KEY" \
  -F "file=@/path/to/document.pdf"

Parsing Behavior Options

Whether parsing starts on upload is controlled by your subscription configuration:

• Automatic parsing (default) — parsing starts as soon as the file is uploaded. You do nothing further; move on to Step 4.
• Manual parsing — the file is stored but not parsed until you trigger it explicitly. Start parsing for the process with:

curl -X POST "https://api.prestatech.com/document-engine/v1/processes/{process_id}/run-parsing" \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Ocp-Apim-Subscription-Key: YOUR_SUBSCRIPTION_KEY"

The response returns the file_ids for which parsing has started. Repeat Step 3 for every document you want to parse in this process.

Step 4: Monitor Parsing Progress

The upload response returns no parsing result — parsing runs asynchronously after upload. There are two ways to learn when a file is done: the recommended "Doc Engine" webhook (the system pushes to you), or an on-demand read of the file by id (you pull).

Webhook Method (Recommended)

Configure the "Doc Engine" webhook in the user portal under Integrations → Webhook to receive automatic notifications when parsing completes. This eliminates the need for polling.

The webhook fires once per file, not once per batch. To detect that a whole batch has finished, match the incoming callbacks against the file_ids returned by /run-parsing — the batch is complete once every id has reported. When parsing is finished, the system POSTs to your configured callback URL a payload equivalent to the response from GET /processes/{process_id}/files/{file_id}.

Reading Status by ID (On-Demand)

You can call GET /processes/{process_id}/files/{file_id} at any time to sync up on a file's parsing status. Use this for on-demand checks or reconciliation — we don't recommend long-polling it to wait for parsing to finish; use the webhook above for that.

Request:

curl -X GET "https://api.prestatech.com/document-engine/v1/processes/{process_id}/files/{file_id}" \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Ocp-Apim-Subscription-Key: YOUR_SUBSCRIPTION_KEY"

The response carries the file's parsing_status and, once complete, its parsing_result.

Step 5: Run Consistency Checks (Optional)

Once the relevant files in a process have been parsed, you can run consistency checks across them — for example, biography and financial-movement consistency, employment checks, and per-document-type recency and consecutiveness. Call this only after all relevant files have been successfully parsed; it works on active (non-archived) processes.

Request:

curl -X POST "https://api.prestatech.com/document-engine/v1/processes/{process_id}/run-checks" \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Ocp-Apim-Subscription-Key: YOUR_SUBSCRIPTION_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "applicant_type": null,
    "file_ids_filter": null
  }'

Both body fields are optional:

• applicant_type — filter the checks by applicant type (e.g. employee, self-employed). null applies the default suite.
• file_ids_filter — restrict the checks to specific file_ids. null or an empty array uses all parsed files in the process.

Response (shape):

{
  "operation_metadata": {
    "used_file_ids": [
      "6f315ea3-268c-4c79-b70b-bf76273058e4",
      "ce3487ea-1cd3-4bcb-a93b-c671f2d0cca2"
    ]
  },
  "basic_checks": {
    "consistent_biography_data": "success",
    "consistent_financial_movements": "failed"
  },
  "employment_checks": {
    "consistent_salary_payslip": "success",
    "consistent_employer_data": "success",
    "consistent_hire_date": "insufficient_data"
  },
  "documents_checks": [
    { "document_type": "it.payslip", "consistent_recency": "success", "consistent_consecutiveness": "success" },
    { "document_type": "it.bank_statement", "consistent_recency": "success", "consistent_consecutiveness": null }
  ]
}

Each check resolves to success, failed, insufficient_data, or null (not applicable). Applicant-type-specific blocks (self_employed_checks, entrepreneur_checks, retiree_checks) are populated only for the matching applicant type and are null otherwise.

Next Steps

• To turn a parsed process into a Plend credit risk report, continue with the Document Parsing + Credit Report guide.
• Repeat Steps 3–4 to add more documents to the same process at any time while it is active.