Which carried files a page claims

Say, page by page, which of the carried files belong to that page, so a hundred statements in one PDF each keep their own data file.

In plain words

Written for anybody. It says what this puts on a sheet of paper, and asks nothing of you beyond that.

A PDF carrying a single file is simple: the file belongs to the document. But send a hundred customers their statement in one PDF, each with the data file that goes with it, and « the document » is no longer the right answer — file number seven belongs to page seven and to no other. This is where you say so. Whoever cuts the big document back into a hundred small ones then knows which file follows which page, without having to guess from a name.

For a developer

Written for somebody who writes the calling program: the model, the units, and the settings that carry the weight.

Written at the top level of a request, under "page_files"

page_files says which of the files declared in attachments each page claims. Every entry names the one-based page it is for and the names of the attachments that page claims. A page named twice claims the files of the last entry given for it, whole rather than merged. A file claimed by no page stays carried by the document itself, which is the shape a single-invoice PDF takes.

Every key, with its default

The reference: which keys are required, which are optional, what each one defaults to and which combinations the server declines.

  • page_files — array, optional, empty by default.
  • page_files[].page — integer, required, counting from 1, as every page number in a request counts.
  • page_files[].files — array of strings, required. The names of the declared attachments the page claims. Each must name one of attachments.

Scope: the pages named. A page named twice takes the last entry given for it, whole: the two lists are not added together.

A whole request that draws it

Post this as it stands and a PDF comes back. Nothing has been left out of it.

{
  "attachments": [
    {
      "name": "first_sitting",
      "file_name": "sitting-1911-03-14.xml",
      "description": "The sitting as a data file",
      "media_type": "text/xml",
      "relationship": "data",
      "modified": "2026-08-03T09:15:00+02:00"
    }
  ],
  "page_files": [{ "page": 1, "files": ["first_sitting"] }],
  "standard_fonts": [{ "name": "sans", "face": "helvetica" }],
  "items": [
    {
      "type": "text",
      "rect": { "llx": 72, "lly": 700, "urx": 523, "ury": 740 },
      "content": ["The sitting this page claims a file for"],
      "font": "sans",
      "font_size": 12
    }
  ]
}

The line that sends it, in three languages

The document as a whole

The numbers the reader shows A hundred letters in a single file What the document says about itself A file still readable in thirty years An invoice a person and a machine both read The address relative links are read against The PDF version the file declares What an image says about itself Files the document carries beside its pages The identity card a single page carries The accessibility standard the document claims

Where to go next

Every key of a request, in one page The other thirty-two settings of a request

See the prices See the examples

Glossary

attachment
A whole file tucked inside a PDF and carried along with it, the way a paper clip holds a sheet to a folder. Opening the document is enough to get it back out. An electronic invoice works this way: the page a person reads carries the same amounts as a file accounting software reads.
request
One call to the service: you send what the document should say, and get the document back. Your bill counts these calls, one for each document. The number of pages inside a document is never counted.

Every word the site explains