Docbooks
Docbooks is booking: take a receipt and produce a bookkeeping job that follows Swiss practice. You talk to Docbooks. The document analysis runs behind the scenes; the partner contract is the booking report — accounts, amounts, VAT — not a Docmind document resource. You do not call the Docmind API first unless the extracted data is also a feature in your product.
Typical buyers: fiduciary software, accounting suites, and banks that already hold the ledger and want Docpier to propose the posting.
What the API does
| For a product manager | For an architect |
|---|---|
| Faster, more consistent postings from paper and PDFs. | Multipart POST of the file to a Docbooks workspace → 202 + bookingJobId. |
| Staff review the proposal and send corrections. | Webhook BOOKING_FINALISED, then GET. Optional include=extraction. |
| Onboard each client organisation once. | Partner → Organisation → Workspace. Writes are async jobs. actor is your user. |
| Postings land on the client's own accounts. | The workspace (or its organisation) needs a chart of accounts, or booking answers 400. |
The core call is Propose a booking. Onboarding exists so that booking has a workspace to land in, and that workspace needs a chart of accounts before it can book. Broader organisation and workspace administration moves to the Management API.
A booking job ends COMPLETED, REVIEW_REQUIRED (a booking exists, with reviewReasons saying what a human should check), or FAILED. Build the review lane before you go live — it is the normal path for anything the model is not sure about, not an error case.
Booking takes the file, not a Docmind document id. A workspace that is not
provisioned for extraction answers 409. Combine analysis and
booking.