How Parsli works

Five objects. Once these make sense, everything else in Parsli is a detail.

The model

A Parser is a reusable setup for one kind of document. It owns everything below it.

Inside a parser:

• Field definition — what you want pulled out. Shown in the app as Fields & Tables.
• Inbound — how documents get in.
• Outbound — where extracted data goes.
• Document — one file you sent, plus the result that came back.

That is the whole structure. A parser for supplier invoices has one field definition, a few ways for invoices to arrive, one or two places the data should land, and a growing pile of documents.

The journey of a document

1. It arrives — uploaded, emailed to the parser's own address, or posted in over the API. All routes are equal; the rest of the pipeline does not care which one was used.
2. Pages are counted. This is what you are charged: one page, one Credit.
3. Parsli's parsing engine reads it against your field definition.
4. A result is produced, with a Confidence signal per field. Values that cannot be grounded in the document are left empty rather than guessed.
5. Outbound integrations fire, each one getting the same result.
6. The document is stored with its result, so you can look at it later or reprocess it.

If extraction fails, the credits reserved in step 2 are returned. You are not charged for failures.

Why a parser is not a template

The word "template" implies a fixed layout — draw a box around where the total lives, and hope the next invoice puts it in the same place.

Parsli does not work that way. The field definition describes meaning, not position. "Total including tax" is a description of what you want; where it sits on the page is the engine's problem. This is why one parser handles invoices from forty suppliers with forty different designs.

The practical rule that follows: make one parser per kind of document, not per sender.

Fields, tables, and nesting

Most fields are simple — a Field type like text, a number, a date.

Two shapes matter more:

• Table field for anything that repeats. Invoice line items, statement transactions. You define the columns once, and get back one row per line found.
• Object field for things that group. A vendor with a name, an address, and a tax number.

Tables are the common case people miss. If your document has a list of things, that is a table field, not five separate fields with numbers on the end.

In and out are separate

Inbound and Outbound are independent, which is what makes the useful patterns possible:

• Invoices arrive by email, land in QuickBooks. Nobody logs in.
• Documents arrive over the API, results come back over a webhook.
• A colleague drops files into the Inbox and the data appears in a Google Sheet.

You can add or remove either side without touching the other.

What this means if you are writing code

The same model, in API terms:

• A parser is addressed by parser_id. An API key is scoped to one parser.
• A document is addressed by document_id and fetched with GET /api/v1/documents/{id}.
• Extraction runs either synchronously or asynchronously. Small files can go inline; large or slow ones must use the async route, or you will hit request timeouts.
• Outbound webhooks carry the same result object the app shows you. There is no second, different shape to learn.

Details in build with the API.

Next

• Defining what to extract — getting fields right is most of the work
• How pages are counted — what a document actually costs
• Dictionary — every term, in plain and precise form