Skip to main content
When Clemta publishes a document on one of your companies, it appears on GET /companies/{id}/files and fires file.created. Formation deliverables, filed state and IRS forms, and letters land here, alongside the files you uploaded yourself. Each file’s source says which it is: operations for a document Clemta published (downloadable), upload for one you sent (write-only). A published document also carries kind (what it is - an EIN letter, a signed document, a form attachment) and, when it came out of a service order, the service_order it belongs to - so you can route a delivered document without opening it.

​
Reading

  • GET /companies/{id}/files - one company’s published documents, newest first: name, content type, size, when it was created.
  • GET /v1/files - everything in your account, paginated, newest first: your uploads and Clemta deliverables alike. Filter by purpose, source, company_id, service_order_id (the documents delivered on one order) or kind (what a published document is - an EIN letter, a signed document, a form attachment, and so on).
  • GET /files/{id} - one file’s metadata.
  • GET /files/{id}/contents - the bytes, streamed with the right Content-Type and Content-Disposition, on your API key. A downloadable file also carries a url pointing at this endpoint. There is no expiring storage link to share or leak.

​
Uploading

POST /v1/files takes multipart/form-data with a file part and a purpose. The purpose sets what is accepted: The bytes are verified against the declared type, and images are bounded per side as well as by size. A mislabeled file is refused with invalid_request.
The response is a file with source: upload. Attach it by id - the only API-side way to deliver a document:
  • to a document requirement ({"document": "file_..."} on fulfill),
  • as a form field’s file value on fulfill,
  • or directly at company create (shareholders[].passport), in which case no requirement opens and, when every owner arrives with a document, the company is handed to fulfillment immediately.
Uploads are single-use (consumed flips true once attached) and write-only: the response carries no download URL, and the contents can never be read back.

​
Letting your customer upload without a key

Your customer can upload a document without holding any credential of yours, through a verification session (POST /companies/{id}/verification-sessions returns a hosted url) or the requirement-link door (PUT /requirement-links/{token}/document). See requirements.

​
Sharing a file

POST /v1/file-links over a shareable file mints a public url that serves the bytes with no authentication until it expires. Only deliverables and branding uploads can be linked - a customer identity document is refused. GET /v1/file-links lists your links, GET /file-links/{id} reads one, and POST /file-links/{id} moves the expiry (set expires_at to now to revoke a URL already in someone’s hands). The public bytes live at GET /file-links/{token}/contents.

​
What is not returned

Identity documents your customers uploaded (passports) are write-only: they go to Clemta for verification and are never listed or served back through the API. Only shareable deliverables are readable. Customer PII stays on your side.
Last modified on October 2, 2026