Summarize PDFs, images, and text with one API call

A third of the tickets in a support inbox carry an attachment: a scanned invoice, a photographed receipt, a contract someone exported to PDF and then photographed anyway. Routing those tickets means knowing what each attachment says, and the cheapest correct answer is rarely the full text. It is a two-line description — an invoice about a canceled subscription, a receipt for a refunded order — that a router, a person, or a downstream model can act on.

The Summarization API is AIVAX's endpoint for that middle step. One POST request takes an array of documents and returns one short summary per document, with the format, language, focus, and length of each summary controlled by an optional instruction string.

One request, one summary per document, in input order

The endpoint is POST /api/v1/generations/summarize. The body carries a documents array where each item is an OpenAI-style content part — text, image_url, or file — plus an optional instructions string:

{
  "instructions": "Summarize in one paragraph, in English, focused on payment terms.",
  "documents": [
    {
      "type": "file",
      "file": {
        "filename": "contract-2026-114.pdf",
        "file_data": "https://example.com/contracts/contract-2026-114.pdf"
      }
    },
    {
      "type": "image_url",
      "image_url": {
        "url": "https://example.com/receipts/receipt-0437.jpg"
      }
    }
  ]
}

Images and files accept base64 data URLs or public HTTP(S) URLs, in JPEG, PNG, TIFF, or PDF — multipage PDFs included. AIVAX downloads public URLs before processing, up to 5 MB each, so the resource must be reachable without sign-in; base64 data URLs are limited by the request size instead. Other content types, such as audio or video, return a 400 that does not identify which document was rejected, so check content types before sending a batch.

The response's data array holds one summary string per document, in the same order as the request. Documents are processed independently, up to four at a time, and the results come back in input order. The independence has a corollary worth knowing before you rely on it: each summary sees only its own document. To summarize several documents as one, send them concatenated as a single text document, or summarize the individual summaries in a second request.

Instructions shape the summary; the document constrains it

The instructions string applies to every document in the request. It can set the format ("three bullet points"), the language ("answer in Portuguese"), the focus ("only the payment terms"), or the length ("maximum 100 words"). The endpoint's contract is that a summary restates the document in new words without adding information or commentary, so instructions can compress and reorganize what is there, but the model is not invited to editorialize.

That contract has a limit the Summarization docs state plainly: summaries are model-generated and can omit or misstate details. For inbox routing, an omission costs a misrouted ticket. For contract review, the summary is a map of the document, not a substitute for reading the clauses that matter — use the summary to decide where to look, then read those pages.

Summarize when the next step needs meaning, not fields

The summarize endpoint shares its request shape with two siblings, and the choice between them is about what the next step in your pipeline consumes.

When the next step needs values — a total due, a due date, line items — use Extraction, which returns one JSON object per document shaped by a schema you provide. When the next step is a person who needs the text of a scanned page or a URL, Fetch returns the full text instead of a condensation. And when the next step is a RAG index, you want the full text too, because a summary collapses exactly the detail that retrieval exists to surface — our pipeline for converting PDFs to Markdown chunks feeds indexes, not summaries. When the next step is a reader in another language, translate the full text instead: extract it and translate it in chunks.

Summarization is the option for the step in between: a triage decision, a routing rule, a digest a person reads before deciding whether the document deserves deeper processing.

Retrying a failed batch: send one document per request

If any document in the batch fails, the request returns an error instead of partial results, and the documents that finished before the failure are billed and count against quota. We walked through the code behind this in extracting structured data from a PDF: each document is billed as soon as its result is ready, and the request runs four documents at a time. Fix the failing document before retrying, because the retry reads everything again. Sending one document per request lets you retry only the one that failed.

Quota is shared with extraction and counts documents, not HTTP requests: the free plan allows 10 documents per minute and 300 per day, Pro allows 100 per minute, Max 1,000 and Ultimate 2,500, per the plans and limits page. A request that would exceed an active window returns 429 before any document is processed, and splitting a batch into smaller requests does not spread the cost, because the unit is the document.

The bill is for reading, not for writing

Summarization is billed at $0.04 per million input tokens, and output tokens are not billed. On most generation APIs the output is the expensive side; here the expensive part is reading the document once, and the condensed result you keep is free. A 40-page contract at roughly 600 tokens per page is about 24,000 input tokens, or under one cent per summary — the 600-token page is an assumption for the arithmetic, not a measured figure.

Pay once to read, route on the summary, and spend extraction or full-text processing only on the documents that turn out to matter.

---

Behavior described here was read from the Summarization documentation and the service implementation on November 1, 2026. On November 10, 2026 the requests in this post were run against the live AIVAX API: a PDF URL and a text document in one request with instructions, and a PNG as a base64 data URL in another, each returning one summary per document in input order; an audio part returned 400 without naming the document; a URL that returned 404 and a URL over 5 MB each returned 400. The concurrency of four, the quota windows and the 429 behavior come from the documentation and the service implementation.