Files

Invoices, receipts, payslips, contracts and ID scans usually travel as attachments. bind.co stores each one as a file, reads it, recognises the documents in it, and uses it as evidence for the records your application receives. This guide covers where files come from, why each one exists only once, what bind.co finds in a file, and every place you meet a file in the API.

Where files come from

Files come from the attachments of the user's mail. bind.co stores them and reads them.

bind.co reads PDFs; Word, Excel and PowerPoint documents, old and new formats; images, including phone photos and scans; plain text and similar formats; and every file inside a ZIP archive.

One file per user, however often it arrives

A file is identified by its content. When the same file reaches the same user more than once, in two emails or forwarded, bind.co keeps one file with one file_id. The same file always has the same id.

What your application can rely on:

• one invoice is one file_id, even if the vendor sent it three times;
• the rule is per user: two users who receive the same file each have their own, with different ids.

What bind.co finds in a file

bind.co summarises each file and recognises the documents in it, such as an invoice, a receipt or a passport, then reads their fields. Here is a file as it appears in an operation's evidence:

{
  "evidence_type": "file",
  "role": "primary",
  "created_at": "2026-10-14T16:04:30Z",
  "email": null,
  "file": {
    "file_id": "fil_2wJyhgOT8GH",
    "file_name": "receipt-2026-10-14.pdf",
    "file_mime_type": "application/pdf",
    "file_summary": {"value": "Delta Air Lines e-ticket receipt, Boston to Chicago, $412.60.", "bind_inference_confidence": 0.9},
    "doc_types": [
      {
        "doc_type": {"value": "RECEIPT", "bind_inference_confidence": 0.93},
        "doc_type_version": 4,
        "requirement_set_satisfied": true,
        "fields": [{"name": "total_amount", "value": "412.60", "bind_inference_confidence": 0.97}]
      }
    ]
  }
}

• file_summary: what the file is, in a sentence.
• doc_types: each document found in the file. doc_type is its kind, with its confidence.
• requirement_set_satisfied: whether the document has every field its kind requires; a missing required field makes it false.
• fields: the values read from the document, each with its own confidence.

A file can hold no recognised document (doc_types empty), or more than one.

Where you meet files

As evidence on operations. A file can be the reason an operation exists, or complete one found in an email. role says how it relates: primary, supporting or related. The same file can be evidence on several operations and has the same file_id on each. See Operations.

As candidates in the chaser. When an operation is missing a required document, the self-help queue can offer files already in the user's mailbox that could be it, each with file_id, file_name, doc_type, and conforms (whether its contents pass the document's checks). Accepting one attaches it to the operation.

In webhooks. documents.suggestion_available carries file_ids:

{"type": "documents.suggestion_available", "data": {"file_ids": ["fil_2wJyhgOT8GH", "fil_4m0ww95XulT"]}}

It names files whose documents have a newer suggestion; re-read the operations that list those files.

What your application should do

• Use file_id as the key for files you show or store. Two evidence items with the same file_id are the same file.
• Show file_name and file_summary to the user; use doc_types to label the file ("Receipt").
• Treat requirement_set_satisfied: false as "this document is incomplete", for example to ask the user for a better copy.
• To show where a file came from, use the email evidence on the same operation: its web link opens the message in the user's mailbox; see Emails.

New attachments reach bind.co through the email sync; see Mailbox sync.