Fields

Fields are the schema of your parser. They decide exactly what parsed_data looks like in API responses, webhooks and exports, so design them with the consuming code in mind.

You edit fields in the parser's Configure Fields tab.

Field names become JSON keys

Each field's Field Name is its key in parsed_data. Pick names your code can use directly:

• Use snake_case, such as invoice_number, invoice_date or total_amount.
• Keep names stable once an integration depends on them. Renaming a field changes the key your code, mappings and exports receive.
• Be specific: vendor_gstin beats id.

Field types

Sections and lists nest. A List of Items called line_items with fields description, quantity and amount produces:

{
  "line_items": [
    { "description": "Steel brackets", "quantity": 50, "amount": 30525 },
    { "description": "Anchor bolts", "quantity": 200, "amount": 17980 }
  ]
}

Use a Number field for anything you'll do arithmetic on, so it arrives as a JSON number and number rules (minimum, maximum, precision) apply.

Required and Unique

• Required. The entry is marked invalid (rule: "required") when this field comes back empty. Use it for values your downstream system can't work without.
• Unique. The value identifies a record, such as the invoice number. Unique fields enable:
  • De-duplication. If a new entry has the same unique value as an existing one in this parser, the existing entry is updated and the new one is marked duplicate, so sending the same invoice twice doesn't create two records.
  • Multiple records per file. has_multiple_entries=true uses the unique field to split a file into separate entries. See Multiple records in one file.

Extracted and derived fields

Most fields are Extracted: read from the document. A field can instead be Derived, meaning its value is filled in after extraction rather than read from the page. For example, Lookup Enrichment takes the value from one of your lookup tables, such as the vendor code that matches an extracted GSTIN. The other modes (Manual Entry and Function) are set up in the same Configure Derived Field dialog.

Derived fields appear in parsed_data like any other field.

Designing a good schema

• Start small. Extract the ten fields you actually use, test, then add more. Every extra field is more to review.
• Model repeating data as a list. Don't create item_1_amount, item_2_amount; use a List of Items.
• Group with sections when your code thinks of values as a unit, such as vendor or bill_to.
• One parser per document family. Two very different layouts are easier to maintain as two parsers.

After changing fields, re-run Test Parser on a few real documents before relying on the new shape.