Field types

The type tells anyformat what kind of value to expect. It shapes how anyformat validates and stores the value. This page is the single source of truth for field types. It lists every type, its name in the UI and in the API, and how to use it well.

All field types at a glance

UI name	API `data_type`	Example value
Text	`string`	`"INV-001"`
Decimal number	`float`	`1250.99`
Integer number	`integer`	`42`
Date	`date`	`"2024-03-15"`
Date & time	`datetime`	`"2024-03-15T10:30:00Z"`
Yes / No	`boolean`	`true`
Select	`enum`	One of a predefined list
Multiselect	`multi_select`	A list of values from a predefined list
Object (Subtable)	`object`	Repeating structured rows

There is no separate list data_type. Use Multiselect (multi_select) for a list of values from a fixed set of options, and Object (object) for a list of structured rows, a subtable. For a free-form list of strings or numbers, model it as an Object with a single nested field.

Not sure which to pick?

A quick guide:

Is it a number with decimals, like a price or percentage? → Decimal number (float)
Is it a whole number, like a count or quantity? → Integer number (integer)
Is it a date without a time? → Date
Is it a yes/no answer? → Yes / No (boolean)
Does it have to be one value from a fixed list of options? → Select (enum)
Could it be several values from that list? → Multiselect (multi_select)
Is it a repeating table, like invoice line items? → Object (Subtable) (object)
Anything else (names, IDs, addresses, free text)? → Text (string)

Picking the right type matters. anyformat returns the value in that shape: a real number you can sum, a real date you can sort. The type also tells the AI what to look for.

Field definition

Every field requires at least:

{
  "name": "field_name",
  "description": "What this field represents",
  "data_type": "string"
}

name: a unique identifier in snake_case.
description: a clear explanation of what to extract. The AI uses it as guidance.
data_type: one of the types listed above.

The complex types object, enum, and multi_select take extra properties, documented below.

Simple types

Text (string)

Best for: values that vary widely, such as company names and addresses.Watch out for: values from a known list. Use Select instead.

Date

Best for: calendar dates when time does not matter. Returned as YYYY-MM-DD.Watch out for: a time in the document. Prefer Date & time.

Date & time (datetime)

Best for: precise timestamps when a document carries a time, not just a date. Returned as 2024-03-15T10:30:00Z.Watch out for: ambiguous timezones and date formats. Add an instruction when the document’s format is unusual.

Decimal number (float)

Best for: money, percentages, measurements.Watch out for: values that should be whole numbers.

Integer number

Best for: counts, quantities, item numbers.Watch out for: currency. Use a decimal number.

Yes / No (boolean)

Best for: clear true/false questions, such as “Is it paid?” or “Is it signed?”.Watch out for: vague cues like “maybe” or “often”. Make the instruction explicit.

Select (`enum`)

Use enum when the extracted value must be one of a predefined set of options. The field requires an enum_options array.

{
  "name": "payment_status",
  "description": "The current payment status of the invoice",
  "data_type": "enum",
  "enum_options": [
    {"name": "pending",  "description": "Payment has not been received"},
    {"name": "paid",     "description": "Payment has been received in full"},
    {"name": "partial",  "description": "Partial payment has been received"},
    {"name": "overdue",  "description": "Payment is past the due date"}
  ]
}

If no option matches the document, the field value is null. Why use Select:

Enforces consistency
Avoids spelling variations
Makes analytics and filtering reliable

Best practices:

Keep options short and unambiguous
Provide clear descriptions for each option
Avoid overlapping meanings
Prefer Select over Text when values repeat

Multiselect (`multi_select`)

Same shape as enum. The field returns multiple matched options as an array.

{
  "name": "document_tags",
  "description": "Categories that apply to this document",
  "data_type": "multi_select",
  "enum_options": [
    {"name": "urgent",           "description": "Requires immediate attention"},
    {"name": "confidential",     "description": "Contains sensitive information"},
    {"name": "reviewed",         "description": "Has been reviewed by a team member"},
    {"name": "pending_approval", "description": "Awaiting approval from management"}
  ]
}

Returns an array of strings:

{ "document_tags": ["urgent", "confidential"] }

Select vs. Multiselect

Feature	Select (`enum`)	Multiselect (`multi_select`)
Selection	Single value	Multiple values
Return type	`string` or `null`	`array` of strings
Use case	Mutually exclusive options	Non-exclusive categories

Object / Subtable (`object`)

Use object to extract a structured group of properties. Object fields require a nested_fields array. anyformat supports one level of nesting only. The children of an object field must be non-object types: string, integer, float, date, datetime, boolean, enum, multi_select. An object field cannot contain another object field.

Single nested object

{
  "name": "shipping_address",
  "description": "Customer shipping address details",
  "data_type": "object",
  "nested_fields": [
    {"name": "street",      "data_type": "string", "description": "Street address including number"},
    {"name": "city",        "data_type": "string", "description": "City name"},
    {"name": "postal_code", "data_type": "string", "description": "ZIP or postal code"},
    {"name": "country",     "data_type": "string", "description": "Country name"}
  ]
}

Repeating rows (Subtable)

Object fields also capture repeating tabular data: invoice line items, transaction rows, any list of things with the same structure.

line_items (object)
  ├── description (string)
  ├── quantity    (integer)
  ├── unit_price  (float)
  └── line_total  (float)

Each row in the document becomes one object in the resulting array. Use Object when:

You see the same set of fields repeating
The document contains a list or table where each row is one item
You need a structured value per row, not a blob of text

Best practices:

Keep subtable fields minimal at first: 3 to 5 columns
Use clear row-level instructions: “Extract one row per item. Ignore headers and totals.”
Add shared fields like currency at the top level, not inside each row
Start with the most reliable columns, description and amount, then expand

Common mistakes:

Using Object for a single nested group, such as a vendor address. That works, but consider whether top-level fields would be simpler.
Making the subtable too wide too early. Past 10 columns, ambiguity rises.
Nesting an Object inside another Object. Only one level of nesting is supported.

Complete example

A workflow definition that uses several field types together:

{
  "name": "Invoice Processing",
  "description": "Extract invoice data with line items",
  "fields": [
    {"name": "invoice_number", "description": "Unique invoice identifier",                  "data_type": "string"},
    {"name": "issue_date",     "description": "Date when the invoice was issued",            "data_type": "date"},
    {"name": "total_amount",   "description": "Total invoice amount including tax",          "data_type": "float"},
    {"name": "is_paid",        "description": "Whether the invoice has been paid",           "data_type": "boolean"},
    {
      "name": "payment_status",
      "description": "Current payment status",
      "data_type": "enum",
      "enum_options": [
        {"name": "pending", "description": "Awaiting payment"},
        {"name": "paid",    "description": "Fully paid"},
        {"name": "overdue", "description": "Past due date"}
      ]
    },
    {
      "name": "vendor",
      "description": "Vendor information",
      "data_type": "object",
      "nested_fields": [
        {"name": "name",    "data_type": "string", "description": "Vendor company name"},
        {"name": "address", "data_type": "string", "description": "Vendor address"}
      ]
    }
  ]
}

Tips for better results

Be specific in descriptions. “The invoice number, usually starting with INV-” beats “Invoice number”.
Use appropriate types. float for amounts and date for dates, never string.
Keep field names consistent. snake_case throughout.
Describe location only when it helps. “Total amount shown at the bottom right” can disambiguate. The AI usually does not need it.

Get started

Nodes

Workflows

Schema & fields

Documents

Outputs & integrations

Health

Billing

All field types at a glance

Not sure which to pick?

Field definition

Simple types

Select (`enum`)

Multiselect (`multi_select`)

Select vs. Multiselect

Object / Subtable (`object`)

Single nested object

Repeating rows (Subtable)

Complete example

Tips for better results

What’s next?

Fields

Instructions

​All field types at a glance

​Not sure which to pick?

​Field definition

​Simple types

​Select (enum)

​Multiselect (multi_select)

​Select vs. Multiselect

​Object / Subtable (object)

​Single nested object

​Repeating rows (Subtable)

​Complete example

​Tips for better results

​What’s next?

Fields

Instructions

All field types at a glance

Not sure which to pick?

Field definition

Simple types

Select (`enum`)

Multiselect (`multi_select`)

Select vs. Multiselect

Object / Subtable (`object`)

Single nested object

Repeating rows (Subtable)

Complete example

Tips for better results

What’s next?