New feature: your Supplier Documents in the API

The documents you receive from your suppliers (purchase invoices, credit notes, ...) are now available in the API.

• GET /supplier-documents: paginated list of your supplier documents, with sorting, free text search and filters on reference, supplier, type, status, issue date, due date and amounts. Requires the read scope.
• GET /supplier-documents/{id}: a single supplier document. Requires the read scope.
• GET /supplier-documents/{id}/pdf: the PDF of a supplier document, encoded in base64, in the same format as GET /documents/{id}/pdf. Requires the read scope.
• GET /supplier-documents/{id}/events: the status history of a supplier document, most recent first. Requires the read scope.
• POST /supplier-documents/upload-asset: upload the PDF of a supplier document and get the temporary key to create it with. Requires the write scope.
• POST /supplier-documents: create a supplier document from an uploaded PDF. Requires the write scope.
• PATCH /supplier-documents/{id}/status: approve, refuse or dispute a supplier document, or declare a payment sent to the supplier. Requires the write scope.

Note: a supplier document whose PDF is not available yet (for example while an uploaded image is still being converted) returns a 404 on the /pdf endpoint. Status changes follow the very same rules as in the INFast app: a transition that is not allowed on the document returns a 400.

Note: creating a supplier document is a two-step import: upload the PDF first, then create the document with the returned assetKey as its fileKey. Only PDFs are accepted, the supplierId must be one of your suppliers, and the created document is a manualImport in the approved status, in euros.

New feature: Supplier Document webhooks

Three webhook events notify you of the changes on your supplier documents, whatever their origin — INFast App, a manual import, or a document received through the e-invoicing network.

• supplier-document.created and supplier-document.updated: the payload is the supplier document, in the same shape as GET /supplier-documents/{id}.
• supplier-document.status-change: the payload carries the updated supplier document and the status it had before, as { "supplierDocument": { ... }, "previousStatus": { ... } }. The new status is not repeated: it is already in supplierDocument.status.

supplier-document.updated is also triggered when the tags of a supplier document change, and is not triggered when only internal fields are modified.

Note: there is no supplier-document.deleted event — the deletion of a supplier document is not exposed in webhooks.

New feature: your Suppliers in the API

The companies you buy from are now available in the API.

• GET /suppliers: paginated list of your suppliers, with sorting, free text search and filters on legal name, legal identifier and tags. Requires the read scope.
• POST /suppliers: create a supplier. Requires the write scope.
• GET /suppliers/{id}: a single supplier. Requires the read scope.
• PATCH /suppliers/{id}: update a supplier. Requires the write scope.
• DELETE /suppliers/{id}: delete a supplier. Requires the write scope.

Note: the legalIdentifier identifies a supplier inside your portal. It must be unique among your suppliers — a duplicate returns a 409 — and cannot be changed after creation. A supplier that still has supplier documents attached to it cannot be deleted and returns a 409.

New feature: Supplier webhooks

Three webhook events notify you of the changes on your suppliers, whatever their origin — the API, INFast App, or a supplier created automatically from a document you received.

• supplier.created and supplier.updated: the payload is the supplier, in the same shape as GET /suppliers/{id}.
• supplier.deleted: the payload only carries the id of the deleted supplier, as { "supplierId": "..." }.

supplier.updated is also triggered when the tags of a supplier change, and is not triggered when only internal fields are modified.

New feature:

It is now possible to specify the VAT exemption type (vatExemptionType) when creating a document via the API.

• vatExemptionType is available in both input and output of document endpoints.
• When vatExemptionType is provided, the amountNotice field is automatically derived from the corresponding legal notice.
• amountNotice can only be set manually when vatExemptionType is CUSTOM_EXEMPTION or CUSTOM_APPLICATION.

More details here.

New field: tradeName on Portal and Documents

The enterprise object of the Portal (and the from field on Documents) now exposes an optional tradeName field.

This field represents the trade name of the company, as opposed to the legal name (name, required for legal compliance).

• Available on GET /portal, PATCH /portal, and all document outputs (from.tradeName).
• When set, the trade name is displayed prominently on PDF documents; the legal name appears below it.
• Fully backward-compatible: existing portals and documents without this field are unaffected.

Improvement:

This version fixes an edge case: document validation when the reference assignment method has not been configured for the portal. This could lead to indeterminate situations.

Now, when validating a document, if the reference assignment method has not been configured, you will receive this error:

The portal needs to choose a ReferenceAssignmentMethod before validating a document

More details about this error here

Note: This change only affects new API users. No impact for existing users.

Improvement: A new date field has been added to the POST /documents/{id}/payment endpoint. This allows you to specify the exact transaction date, just like in the INFast app.

Check the details in Add Payment on Invoice API Reference

New Feature: Added an optional type field to the Customer object, allowing you to distinguish between business (business) and individual (consumer) customers.

Currently, this field is optional but will become mandatory in a future update to comply with French regulations.

For now, if the type is not provided, it is automatically inferred based on the presence of a siret: if a siret is detected, the customer is considered a business, otherwise a consumer.

Check the details in Create Customer API Reference

Version 2.0.1 is a maintenance release focused on tightening Webhook behaviour so that it matches the published documentation.

Fixes

• Webhook identifier is now returned in the id property (formerly _id).
• Payload structure: resources are no longer wrapped in an extra layer; you’ll find them directly under data (e.g. data instead of data.document).

The OpenAPI specification has been refreshed to mirror these fixes, but only wording and formatting were touched—nothing that alters functionality or breaks existing integrations.

INFast API 2.0 is a big milestone for the Intia team. This changelog lists all the changes compared to INFast API 1.0.

The objectives of this new version are:

• Clean up the API design for more consistency,
• Provide a foundation for our future developments,
• Support a global overhaul of INFast.

You may also notice a change in the documentation. Indeed, we have decided to switch to Docusaurus. The goal is to provide you with cleaner, more functional documentation. You can easily make test requests directly in the API documentation. Here are the updates:

• Add webhooks
  • invoice.validated
  • invoice.paid
  • quotation.validated
  • quotation.accepted
  • quotation.refused

• Deprecated fields:
  • Remove status during document creation. All documents are created with status "VALIDATED"
• Deleted fields
  • isCreditNoteInvoice, isSituationInvoice and isDepositInvoice are deleted, API allow creation of quotation and invoice but not specific document.
• Add field
  • "Document model Output" have a new field allow to know the subtype (CREDIT_NOTE, PROFORMA, ...)
• Add endpoint to pay an invoice
• Search customer allow to search by email

• INFast API public release
• Add rate limiting (10 requests per second max)
• Add INBox URL in response of /documents/{id}/email
• Add units to the product model
• Add webhooks
  • document.created
  • document.updated
  • document.deleted
  • customer.created
  • customer.updated
  • product.created
  • product.updated