Collect guide

How a request is structured, participants, checks on upload, reminders and export. In the app, Collect is called Deposits.

How a request is structured

A request is made up of documents, grouped by participant. A document can require several files (for example front and back) and can be conditional (“if the property is part of a condominium”).

Validation criteria

Per document: extension, size, file name and number of files. In the API, these criteria are written as a rules expression:

extension:eq:pdf|and|size:lt:5000000

A document type (slot_type) carries its default rules and its rejection reasons.

Rejections with reasons

Each rejection reason has a title and a message shown to the contributor, for example Signature — The document is not signed. The contributor understands what is wrong and uploads again right away.

Automatic check on upload

A reason marked llm: true is evaluated at upload time: if it triggers, the file is rejected, no file is created and the upload.refused event is emitted. A llm: false reason is suggested during manual review. The final decision is always yours.

Reminders

A schedule is attached to each template: delays (D+3, D+7, D+14), channel (email, SMS), message. It stops automatically for each document received. Manual reminders are available per participant, per file or in bulk.

Recurring requests

A recurrence creates and sends the request automatically at regular intervals: every month, quarter or year. Typical cases are monthly VAT or expense reports.

Retrieving files

From the app, a complete file can be exported as a .zip. Through the API: GET /deposits/{public_id}/uploads lists the received files, then GET /uploads/{id}/download returns the file. To be notified without polling the API, subscribe to upload.created and deposit.directory.completed (webhooks).