Hubflow public API

Version: v1 · Base URL: https://<your-domain>/api/v1

Summary version. The full documentation (fields, request and response examples) is to be restored from the original api.html file.

1. Overview

The public API lets your applications drive deposits: create a document request, invite the people involved, track progress and retrieve the files received.

Data model

A deposit (deposit) is a document request. It contains slots (the requested documents: “ID card”, “RIB (bank details)”…) and recipients (directory, the people asked for these documents). Each file uploaded by a recipient into a slot is an upload. A slot type (slot_type) is a reusable slot template, with its validation rules and checks.

Versioning

The version number is in the URL. New fields or endpoints are added without a version change: your integration must ignore unknown fields. A removal or a change in meaning will lead to a v2.

2. Quick start

1. Create an API key from your workspace settings. The full value is shown only once, at creation: copy it right away.
2. Call the API with this key in the authentication header.

3. Authentication

Every route requires an API key. A key gives access to a single workspace, with the rights of the user who created it. Hubflow stores only the SHA-256 hash of the key. A revoked key is rejected immediately (API_KEY_REVOKED).

Environments: live and test. There is no isolated sandbox yet: a test key reads and writes the same data as a live key.

4. Resources

• Account: GET /account
• Deposits: create, list, read, update
• Slots: the documents in a deposit
• Recipients: invite, send reminders
• Received files: GET /deposits/{public_id}/uploads, then GET /uploads/{id}/download
• Contact lists
• Slot types: document templates and their rules (rules, for example extension:eq:pdf|and|size:lt:5000000)

5. Known limitations

No isolated sandbox, and no per-key scopes yet (read-only…). Pre-v1 routes remain active but must not be used for new integrations.