Introduction

Read and write a company’s data over a stable HTTP interface.

The Fidly API lets a partner or third-party integration read and write a company’s data: documents (invoices, credit notes, received documents), relations, bank accounts, journals and brandings.

Base URL

https://api.fidly.be

All requests use HTTPS and JSON (except file upload and download endpoints, which use multipart/form-data and raw bytes).

Resources

Resource	Read	Create	Update	Delete
Documents	✅	✅	✅	✅
Relations	✅	✅	✅	✅
Delivery locations	✅	✅	✅	✅
Bank accounts	✅	✅	✅	❌
Journals	✅	✅	✅	❌
Brandings	✅	❌	🟠	❌
Reference lists	✅	❌	❌	❌

Legend:

• ✅ available
• 🟠 partially implemented — the endpoint exposes only part of the resource
• ❌ not available

🟠 Brandings — the PATCH only lets you designate the default branding; no other field can be modified.

The business conditions of an action (edit lock on a sent document, fields fixed at journal creation, deletion refused while other objects still reference the targeted one…) are detailed on each resource’s page.

The API is more permissive than the interface. A document created through the API may therefore hold combinations the web or mobile application cannot represent, and displaying or editing it from the application may then cause issues. This applies in particular to VAT rates other than the Belgian legal rates (0, 6, 12 and 21 %), and to discounts and charges as soon as there is more than one per line or per document — without being limited to these two examples.

Environments

Each API client works in one of two environments:

• Live — the company’s real data, for both reads and writes.
• Sandbox — an isolated environment to develop and test: demo data, the exact same validations and error codes as live, and no stored changes. See Sandbox.

The environment is determined by your credentials: a client_id / client_secret pair belongs to either live or sandbox, and is obtained from the Fidly interface.

Authentication

Authentication relies on the OAuth2 client credentials flow. A call to POST /auth/token with your client_id / client_secret pair returns your access_token and refresh_token keys; every API call then carries the access_token in the Authorization header. See Authentication.

Errors

All errors share one envelope with a machine-readable code and a human-readable message. See Errors.