DocExtract Mega guide

Business is the name used on this site for RapidAPI's Mega plan. The live pricing page lists $50/month, 50,000 requests/month, and a hard request limit, checked on September 20, 2026 following a 2026-09-20 price reduction from $99/month.1 It separately lists a 10,240 MB monthly bandwidth allowance and a $0.001-per-MB platform charge above that allowance; consult RapidAPI for current billing terms.1

Business adds deterministic correction of selected extracted fields, optional normalization rules, and a per-operation audit trail. The underlying extraction templates and input limits are the same as other plans.

How Business access works

Use your subscribed RapidAPI application and its subscriber key. The marketplace endpoint is:

https://docextract-ai-document-data-extractor.p.rapidapi.com/extract

DocExtract enables the postprocessing pass only when the service feature is enabled and the request carries both the trusted RapidAPI proxy credential and an allowed subscription value. The deployed subscription value is MEGA.

RapidAPI supplies those provider-facing headers. Do not set X-RapidAPI-Subscription or request an X-RapidAPI-Proxy-Secret for your client. Your client sends X-RapidAPI-Key and X-RapidAPI-Host as shown below. A direct X-API-Key or Bearer request can authenticate extraction, but those credentials alone do not enable Business postprocessing.

Correction runs automatically on eligible requests. There is no separate correction endpoint, and no per-request switch to disable only the built-in correction phase. The normalization object is optional.

Making a request

Set RAPIDAPI_KEY in your own environment to your subscribed application's key. Save the following JSON as business-request.json, or download the example request.

{
  "document_type": "invoice",
  "content": "INVOICE INV-1001\nVendor: ACME Ltd.\nInvoice date: 2026-09-18\nDue date: 2026-10-18\n2 Gadget at 100.00 each\nSubtotal: 200.00\nTax: 10.00\nTotal: 210.00 CAD",
  "normalization": {
    "date_format": {
      "invoice_date": "US",
      "due_date": "ISO"
    },
    "numeric_format": {
      "total_amount": "CURRENCY",
      "line_items[0].unit_price": "NUMBER"
    },
    "text_substitute": {
      "vendor_name": {
        "from": "Ltd.",
        "to": "Limited"
      }
    }
  }
}

curl --request POST \
  --url 'https://docextract-ai-document-data-extractor.p.rapidapi.com/extract' \
  --header "X-RapidAPI-Key: ${RAPIDAPI_KEY}" \
  --header 'X-RapidAPI-Host: docextract-ai-document-data-extractor.p.rapidapi.com' \
  --header 'Content-Type: application/json' \
  --data-binary @business-request.json

The model extracts the document first. DocExtract then applies built-in correction, followed by your normalization rules. data contains the final values; the normal response envelope still includes success, document_type, engine, and processing_ms. Model output can vary, and fields absent from the document may be omitted.

A successful HTTP response is not a guarantee of a valid document schema. Non-JSON model output can return warning: "non-JSON output" with text in data.raw_text. Other unexpected JSON shapes can bypass correction. Validate the response shape and required fields in your application.

Field paths

Rule paths are relative to the extracted object inside data:

• invoice_date addresses a top-level field.
• line_items[0].unit_price addresses one field on the first line item.
• action_items[0].due_date addresses one meeting action's due date.
• extracted_fields.total_amount addresses a nested general-document field, if the model returned that exact name.

Do not prefix paths with data.. Paths are case-sensitive and use dotted object keys and zero-based array indexes. Wildcards, quoted bracket keys, negative indexes, and array-wide rules are not supported. Object-key segments must begin with a letter and contain only letters, digits, or underscores. A path may be at most 200 characters long.

Rules do not create missing fields. A valid rule with a missing path, an unsuitable value, or no value change can silently do nothing. Compare the response against your own required-field checks.

Built-in OCR-style correction

This phase works on extracted JSON, not on the original PDF or image. It recursively checks leaf fields by their exact names:

• Numeric fields: subtotal, tax_amount, total_amount, value, quantity, unit_price, total.
• Date fields: date, invoice_date, due_date, effective_date, expiration_date, next_meeting.
• Identifier fields: invoice_number, contract_number, id, identifier, reference.
• Currency field: currency.

For numeric strings, it can repair selected letter/digit confusions when the resulting value matches the numeric pattern. "21O.OO" becomes the JSON number 210.0. Date correction accepts a parseable date after its separator/glyph cleanup; it does not infer a missing year or resolve ambiguous day/month order.

Identifier corrections are advisory only. When a confused glyph sits between digits (for example INV-10O1), the original value is preserved in data and an advisory audit entry is emitted with advisory: true and suggested: "INV-1001". Prefixes such as INV, BOX, and RESTORE stay intact. Ambiguous all-glyph identifiers such as "I1l" are preserved with no advisory.

This change prevents silent corruption of legitimate business codes that use letters deliberately (for example PO-1O5 region code O, AC-1B5 Bristol branch B, BL-2S9 sea freight S, LC-7I2 tranche I, AB-5I7 roman numeral I). Integrators should surface advisory entries for human review rather than auto-applying suggested.

Currency cleanup recognizes CAD, USD, EUR, GBP, and AUD after case/glyph cleanup. It does not identify an unknown currency or perform an exchange-rate conversion.

These heuristics can still be wrong. They cannot recover missing OCR text, fix arbitrary prose, reconcile totals, or verify the extracted facts against another system.

Date formats

normalization.date_format maps paths to one of the following case-sensitive format names:

The final field name must be one of the date fields listed above. In particular, resume start_date and end_date fields are not supported by the date-format validator. Values must be strings parseable as ISO dates after the correction phase. This is date formatting, not natural-language date parsing or timezone conversion.

Numeric representations

normalization.numeric_format maps supported numeric-field paths to:

Input must be a finite number or a strict decimal string. Boolean values, currency symbols, thousands separators, and scientific-notation strings are not supported by this formatter. An unsuitable value is left unchanged.

CURRENCY uses decimal rounding; the current default rounds ties to even ("2.345" becomes "2.34"). It adds neither a currency code nor a symbol, and it does not convert currencies. DECIMAL does not restore precision that the model or a floating-point value has already lost. JSON numbers should not be used when your application requires exact decimal-string representation.

Validate numeric range too. The current NUMBER conversion can overflow very large fractional values to Infinity, which strict JSON readers reject. Prefer decimal strings for large or precision-sensitive amounts and validate the final response rather than relying on the format label.

Literal text substitution

normalization.text_substitute maps a path to an object containing exactly from and to:

{
  "vendor_name": {
    "from": "Ltd.",
    "to": "Limited"
  }
}

The example is the value of text_substitute, not a complete extraction request. Replacement is case-sensitive, replaces every matching occurrence within that one string field, and does not support regular expressions or fuzzy matching. It is not an instruction to the extraction model.

Each from and to must be a string of at most 100 characters. from must not be empty; an empty to can remove matched text. ASCII control characters and certain prompt/code-like patterns are rejected. Non-string target values are left unchanged.

Reading the correction audit

When the Business pass completes, the top-level correction object has:

• method: "deterministic_ocr_and_normalization".
• changes: an array of entries with path, before, after, method, reason, and two optional keys for identifier advisories: advisory (boolean) and suggested (string).
• applied: true only when at least one change actually mutated data (before != after). Advisory-only entries (where before == after) do not set this true. A normalization configuration rejection still sets applied: true. Note: changes can be nonempty while applied is false (advisory-only entries are present but do not set applied); consumers should iterate changes checking the advisory flag rather than gating on applied.

Entry methods are deterministic_ocr or normalization. Entries record changes in phase order: correction first, normalization second. The same field can appear twice. A normalization entry's before value may already include OCR correction; it is not necessarily the value in the original document.

No-op rules do not create entries. An eligible request with no changes normally returns applied: false and changes: []. Identifier advisories are created (with advisory: true and before == after) because they carry a proposed correction that was deliberately not applied.

Advisory entries carry advisory: true and suggested: "". Integrators should surface these for human review rather than auto-applying suggested, since the original identifier may be intentionally non-numeric.

Verified synthetic example

The following already-extracted object was run through the deployed postprocessing functions with the normalization rules used in the request example. This is a deterministic fixture, not a captured response from the model or RapidAPI gateway.

{
  "vendor_name": "ACME Ltd.",
  "invoice_number": "INV-10O1",
  "invoice_date": "2026/09/18",
  "due_date": "2026-10-18",
  "total_amount": "21O.OO",
  "currency": "c4d",
  "line_items": [
    {
      "description": "Gadget",
      "quantity": 2,
      "unit_price": "100.00"
    }
  ]
}

The postprocessing result was:

{
  "data": {
    "vendor_name": "ACME Limited",
    "invoice_number": "INV-10O1",
    "invoice_date": "09/18/2026",
    "due_date": "2026-10-18",
    "total_amount": "210.00",
    "currency": "CAD",
    "line_items": [
      {
        "description": "Gadget",
        "quantity": 2,
        "unit_price": 100
      }
    ]
  },
  "correction": {
    "applied": true,
    "method": "deterministic_ocr_and_normalization",
    "changes": [
      {
        "path": "invoice_number",
        "before": "INV-10O1",
        "after": "INV-10O1",
        "method": "deterministic_ocr",
        "reason": "identifier OCR confusion suggested (advisory, not applied)",
        "advisory": true,
        "suggested": "INV-1001"
      },
      {
        "path": "invoice_date",
        "before": "2026/09/18",
        "after": "2026-09-18",
        "method": "deterministic_ocr",
        "reason": "date separators/OCR confusion normalized"
      },
      {
        "path": "total_amount",
        "before": "21O.OO",
        "after": 210.0,
        "method": "deterministic_ocr",
        "reason": "numeric OCR confusion repaired in a numeric field"
      },
      {
        "path": "currency",
        "before": "c4d",
        "after": "CAD",
        "method": "deterministic_ocr",
        "reason": "currency code normalized"
      },
      {
        "path": "vendor_name",
        "before": "ACME Ltd.",
        "after": "ACME Limited",
        "method": "normalization",
        "reason": "text substituted 'Ltd.' -> 'Limited'"
      },
      {
        "path": "invoice_date",
        "before": "2026-09-18",
        "after": "09/18/2026",
        "method": "normalization",
        "reason": "date format normalized to US"
      },
      {
        "path": "total_amount",
        "before": 210.0,
        "after": "210.00",
        "method": "normalization",
        "reason": "numeric representation normalized to CURRENCY"
      },
      {
        "path": "line_items[0].unit_price",
        "before": "100.00",
        "after": 100,
        "method": "normalization",
        "reason": "numeric representation normalized to NUMBER"
      }
    ]
  }
}

The omitted model-extraction envelope is not part of this fixture. A real request's engine, processing_ms, extracted fields, and initial values depend on that extraction.

Limits and rejection behavior

• Maximum content length: 16,000 characters after outer whitespace is trimmed.
• Maximum request body: 64,000 bytes, including normalization and JSON encoding.
• Maximum normalization rules: 20 across all three sections combined.
• Maximum normalization size: 2,048 bytes after compact UTF-8 JSON serialization. This is separate from the overall body limit.
• A field path may have only one normalization operation, including across different sections.
• Only date_format, numeric_format, and text_substitute are accepted inside the normalization object.
• Rule names and paths are case-sensitive; format enums must use their documented uppercase spelling.

For an invalid normalization object, validation normally rejects the entire normalization configuration and appends an audit entry at normalization_config. That entry has after: null and a reason beginning invalid configuration:. Built-in OCR correction can still be present in data. The extraction can return HTTP 200, and applied can be true because the rejection itself is an audit entry.

If normalization is not an object, the current HTTP handler ignores it; eligible built-in correction can still run. If a rule path is simply absent, the value cannot be formatted, or a substitution has no match, that operation is a no-op rather than a configuration error. Do not rely on an audit entry for every requested rule.

Unexpected postprocessing errors preserve the original extraction and can leave correction absent. Some malformed configurations can follow this fallback instead of producing a rejection audit. Check the presence and contents of correction, then validate the final values before importing them. This step is not an extraction-accuracy guarantee.

Quotas, throttling, and scope

Mega's monthly request quota is a marketplace billing limit, not a separate origin throughput guarantee.1 The origin still applies 20 requests per 60 seconds per existing rate bucket. Traffic using the same trusted RapidAPI proxy credential shares a bucket; it is not isolated per subscriber. The marketplace can also apply its own restrictions. A 429 response does not mean your monthly quota is necessarily exhausted.

Business supports the same invoice, resume, meeting_notes, contract, and general extraction templates. The field-name and value restrictions above determine which normalization operations can apply. It does not add OCR/file uploads, larger documents, batch submission, a dedicated model, priority processing, an SLA, or guaranteed accuracy.

The postprocessing rules do not make another model call. Initial extraction still uses the model provider described in the terms of use.

If a rule appears not to work

1. Confirm that the request went through the RapidAPI hostname with the intended Mega subscription. Do not try to force entitlement with a client-supplied tier header.
2. Look at the actual response data. Use the exact field path and array index it contains, without a data. prefix.
3. Check correction.changes for a normalization_config rejection. applied: true can include that rejection.
4. Check the target's type and format. Missing paths and unsuitable values can remain unchanged without an audit entry.
5. If correction is absent, eligibility or a skipped postprocessing pass may be responsible. Contact the API provider with a sanitized example rather than your key or a sensitive document.

Related resources: Business feature overview, quickstart, OpenAPI specification, and working notes on OCR text.

Sources

[1] DocExtract RapidAPI pricing (live, 2026-09-18) (accessed 2026-09-18).