Documentation API

Informations about your e-Attestations Account and statistics like the number of thirdparties you monitore on e-Attestations

Account's requirements are the documents you are allowed to ask to your thirdpartis in your dossiers.

It depends on your e-Attestations configuration that you've designed with the help of you key account manager or automaticaly with your e-attestations subscription.

Account's thirdparties list and details.

All account's dossiers.

The 'dossier' resource is the materialization of the client / third party relationship.

In the response :

• monitored : active / inactive dossier
• state : true for an active and complete dossier
• thirdpartyState : true for a registered user
• stateLastChangeDate : complete / incomplete date for an active dossier (null for an inative dossier)

Dossier creation is an asynchronous process, you can find more details here

Add notes on your dossier. They will be visible when you do a GET on a dossier.

get all evidences :

• a form filled
• a document fetched
• a document uploaded

Each evidence is a file ( binary file + informations).

Contexts let you group the third parties you monitor around a specific business situation — a public tender, a project, a purchasing campaign — and follow their compliance together.

Key concepts

• Context model — a ready-made template defined for your account (its name, the attributes it carries, and whether a supply-chain declaration is expected). You choose a model when you create a context.
• Context — one concrete instance of a model (e.g. "Tender 2026-001"), with its own reference, attributes and third parties.
• Context third party — a third party attached to a context. Third parties can be organised as a tree (a supplier and its sub-suppliers) when the supply-chain option is enabled on the context.
• Notes — free comments you can attach to a context or to one of its third parties.

Typical flow

1. List context models to get the model name to use.
2. Create context from that model.
3. Attach third parties (at first level, or as a full supply-chain tree).
4. Follow up with attributes, dossiers and notes.

The third parties attached to a context.

They can form a tree: a first-level third party, its sub-suppliers (children), and so on — when the supply-chain option is enabled on the context. Each third party in the tree has its own id (called a context third party id), distinct from the third party's own identifier.

Query your third parties, dossiers and documents with a criteria builder: a tree of boolean conditions (AND / OR) that you compose freely, over any field available for your account.

📖 For an illustrated, step-by-step walkthrough of the concepts, see the Advanced Search concept guide.

How it works — 3 steps

1. Discover the filterable fields — first call reference-data (endpoint below). It returns, for your account, the list of fields you can filter on, each with: its technical name (field), type (fieldType), nature (nature), resource (resourceType), allowed operators (availableOperators) and, for coded fields, the possible values (options).

2. Build the query — copy these descriptors into the conditions of your filters tree (see "Anatomy of a condition" below). Each condition's field always comes from reference-data: you never invent a field name or a coded value.

3. Search or export — send the request to the search endpoint of the target resource (Third parties / Dossiers / Documents), or to its export twin to get a file.

Anatomy of a condition

A condition = a field + an operator + values:

{
  "field": {
    "field": "addressCountryCode",
    "fieldType": "TEXT",
    "nature": "MAIN_FIELD",
    "resourceType": "THIRD_PARTY"
  },
  "operator": "EQUAL",
  "values": ["FR"]
}

A condition can target a resource other than the one queried (cross-resource filtering) via its resourceType — e.g. find third parties that have a dossier of a given type.

Filter groups: childGroups (nested AND / OR)

A group has a single connectiveOperator (AND or OR) that joins all its conditions and all its childGroups. To mix AND and OR, nest sub-groups in childGroups — depth is unlimited.

Example — third parties FR AND (headcount ≥ 50 OR turnover ≥ 1,000,000):

{
  "filters": {
    "connectiveOperator": "AND",
    "conditions": [
      {
        "field": { "field": "addressCountryCode", "fieldType": "TEXT", "nature": "MAIN_FIELD", "resourceType": "THIRD_PARTY" },
        "operator": "EQUAL",
        "values": ["FR"]
      }
    ],
    "childGroups": [
      {
        "connectiveOperator": "OR",
        "conditions": [
          {
            "field": { "field": "workforce", "fieldType": "NUMERIC", "nature": "MAIN_FIELD", "resourceType": "THIRD_PARTY" },
            "operator": "GREATER_OR_EQUAL",
            "values": ["50"]
          },
          {
            "field": { "field": "turnover", "fieldType": "NUMERIC", "nature": "MAIN_FIELD", "resourceType": "THIRD_PARTY" },
            "operator": "GREATER_OR_EQUAL",
            "values": ["1000000"]
          }
        ],
        "childGroups": []
      }
    ]
  }
}

The root group applies AND between the "country = FR" condition and the sub-group; the sub-group applies OR between its two conditions.

🔍 Advanced Search Endpoints

These three endpoints (thirdparties, dossiers, and documents advanced-search) allow you to perform complex multi-criteria searches with flexible filtering logic.

Filter Logic:

• Within a single criteria object: All fields are combined with AND logic

  • A result must match ALL specified criteria

• Between multiple criteria objects: Results are combined with OR logic

  • A result must match ANY of the criteria objects

Example:

{
  "filters": {
    "dossiers": [
      {
        "dossierType": "SUPPLY_CONTRACT",
        "status": "VALID"
      },
      {
        "dossierType": "PARTNERSHIP",
        "status": "IN_PROGRESS"
      }
    ]
  }
}

This searches for:

• Dossiers that are (type = SUPPLY_CONTRACT AND status = VALID)

• OR

• Dossiers that are (type = PARTNERSHIP AND status = IN_PROGRESS)

This flexible approach allows you to build complex queries that match your specific business needs.

Here are the HTTP Status Codes and Error Codes used by our API:

In case you receive a 400 ou 500 Http Status Code, you will find in the response a custom error code which give more information on the error cause: