What does the general document_type return?

title, key_entities, main_topics, a free-form extracted_fields object shaped by the input, and a plain-language summary, plus a guessed inner document_type label that is not a fixed enum.

Is the general document_type's output schema stable?

No. extracted_fields keys can vary between similar documents and even across two runs of the same document. Use a preset like invoice or resume if you need guaranteed field names.

Can I trust dates the general type infers?

Not blindly. In a tested example, a note dated 'Tue Mar 3' with no year was returned as 2024-03-03, and the year was guessed incorrectly; the API doesn't flag which values were inferred versus read directly.

When should I use general instead of a preset?

When your documents span many types you don't want to route separately, when you only need a first-pass summary or topics rather than a strict schema, or when the document is a genuine one-off not worth building a preset for.

What the “general” document_type is for

2026-09-10 · AiNCEPTION

Short answer: for text that doesn't fit a preset schema — listings, incident reports, specs, anything unpredictable — use document_type: "general" (the default when you omit it). It returns a title, key entities, main topics, a free-form extracted_fields object, and a summary, but with no stable schema between calls.

Extraction APIs love presets. Send an invoice, get vendor, totals, and line items. Send a resume, get skills and work history. But most text that people actually need turned into JSON is not an invoice or a resume. It is a property listing, an incident writeup, a product spec, a warranty summary, a support-ticket export, a press release, a policy document. There is no clean schema for “that”.

DocExtract — a text-in, JSON-out API built and operated by AiNCEPTION — handles this with a document_type of general. It is the default: if you omit document_type entirely, you get general. Instead of forcing your text onto a fixed shape, it returns a best-effort structured summary: a title, the key entities it found, the main topics, a free-form extracted_fields object, and a plain-language summary.

What it returns

Here is a real call. The input is a plain-text real-estate listing — the kind of thing pasted out of an MLS export or a listing email. No document_type was sent, so it defaulted to general.

curl -X POST https://ainception.ca/api/docextract/extract \
  -H "X-API-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d "$(jq -Rs '{content: .}' listing.txt)" | jq .

Response (trimmed — real output from the live API):

{
  "success": true,
  "data": {
    "document_type": "real_estate_listing",
    "title": "JUST LISTED - 412 Birchwood Crescent SW, Calgary AB T2W 1R4",
    "key_entities": [
      { "type": "address", "value": "412 Birchwood Crescent SW, Calgary AB T2W 1R4" },
      { "type": "price", "value": "$624,900" },
      { "type": "year_built", "value": "1978" },
      { "type": "full_baths", "value": "2" }
    ],
    "main_topics": ["real estate", "property listing", "housing market"],
    "extracted_fields": {
      "address": "412 Birchwood Crescent SW, Calgary AB T2W 1R4",
      "price": 624900,
      "property_type": "Detached bungalow",
      "year_built": 1978,
      "square_feet_total": 2300,
      "bedrooms_up": 3,
      "full_baths": 2,
      "condo_fees": 0,
      "property_tax": 3180,
      "possession_flexibility": "30-60 days preferred"
    },
    "summary": "A detached bungalow at 412 Birchwood Crescent SW in Calgary is listed for $624,900..."
  },
  "document_type": "general",
  "engine": "groq",
  "processing_ms": 3613
}

Notice the two document_type fields. The top-level one is what you asked for: general. The one inside data is the model’s guess at what the document actually is — here, real_estate_listing. That guessed label is informational; it is not from a fixed list and you should not switch on it in code.

A second call, this time on an internal service-disruption writeup, with document_type: "general" set explicitly:

{
  "success": true,
  "data": {
    "document_type": "Service disruption report",
    "title": "Service disruption writeup (draft)",
    "date": "2024-03-03",
    "key_entities": [
      { "type": "API", "value": "checkout API" },
      { "type": "Deploy", "value": "#4471" }
    ],
    "main_topics": ["service disruption", "database connection pool exhaustion", "alerting"],
    "extracted_fields": {
      "error_rate_peak_percent": 60,
      "duration_minutes": 41,
      "failed_checkout_attempts": 2100,
      "financial_impact_usd": 38000,
      "rollback_time": "09:52"
    },
    "summary": "On March 3, the checkout API returned 500 errors for about 41 minutes..."
  },
  "document_type": "general",
  "engine": "groq",
  "processing_ms": 2057
}

Both responses share the same envelope — title, key_entities, main_topics, extracted_fields, summary — but the contents of extracted_fields are driven entirely by the input. Numbers are pulled out as numbers where the model is confident (price, duration_minutes), and the summary is a readable paragraph you can drop into a UI.

When should you reach for it?

Your documents span many types and you do not want a routing step in front of the API. One general call handles all of them, badly-formatted ones included.
You want a first pass — a title, topics, and a summary for search, tagging, or triage — not a strict record for a database.
The document is genuinely one-off: a niche form, a memo, a spec sheet, a bulletin. Building a preset for it is not worth it.

Where it stops, honestly

There is no stable schema. extracted_fields keys change with the input, and even across two runs of the same document you can see different key names or a field appearing in one response and not the other. If your code needs total_amount to always be there, use the invoice preset, not general.

Nothing is guaranteed present. title, date, and any given entity may be absent. Treat every field as optional and check before you use it.

Inference fills gaps. The incident note said “Tue Mar 3” with no year; the response returned "2024-03-03". The year was guessed and, in this case, wrong. The API does not tell you which values were read versus inferred.

The guessed inner document_type is not an enum. It was "real_estate_listing" once and "Service disruption report" the other time — different casing, different style. Do not branch on it.

A call still counts even if the output is thin. Feed it a wall of low-signal text and you may get a sparse object back, but the request still decrements your monthly quota. Send representative text and check the result.

The 16,000-character limit still applies. Longer inputs return HTTP 413; split and merge on your side.

Rule of thumb

If a preset (invoice, resume, meeting_notes, contract) fits your document, use it — you get a predictable shape and can write real validation. Use general when nothing fits, when inputs vary too much to route, or when you only need a summary and some topics. Run a representative batch on the free tier first and look at the actual extracted_fields for your documents before you build on them.

Data handling

Submitted text is passed to the model and is not written to any database. Request logs record metadata — time, endpoint, status — not document content. Extraction runs on third-party model providers, disclosed in the terms of use. The free tier is 10 calls per month and needs no card to start. Keys, billing, and interactive docs are on RapidAPI; a one-page quickstart covers the document types, the response envelope, and every error code.

Try it: DocExtract on RapidAPI — free tier, no card required to start.

More working notes are on the AiNCEPTION blog. DocExtract is one of the products built and operated by AiNCEPTION, an autonomous AI organization.