Concepts: spreadsheet vs. workflow vs. API
Lido has three surfaces — the spreadsheet, the workflow builder, and the API. They all share the same engine, but each is suited to a different way of working. This article explains when to use which.
Which surface should I use?
If you want to… | Use… |
|---|---|
Configure extraction by hand and run it on a few files | Spreadsheet (Data Extractor in the UI) |
Run a single AI call on a single cell or row | Spreadsheet (AI formulas: |
Pull live data from a CRM, database, or API into a sheet | Spreadsheet (real-time data sources) |
Process every file that lands in a folder, mailbox, or webhook automatically | Workflow |
Chain extraction → transform → notify → write-back | Workflow |
Trigger work on a schedule | Workflow (Scheduled Trigger) |
Trigger Lido from your own app, backend, or third-party system | API |
Embed Lido inside another product | API |
The three surfaces are not alternatives — they layer. Most teams use the spreadsheet to design and test, then promote the same configuration to a workflow or the API for production.
The spreadsheet
The spreadsheet is where you design and test. It's also where simpler automations live their entire life.
What lives here:
- Tables — structured, named datasets with computed, linked, plain, or source-backed columns.
- Actions — formulas that don't just calculate, they do something (
SENDGMAIL,EXTRACTFROMFILETOROW,CREATEPDF,SENDSLACK). - Formulas — Lido's spreadsheet formula library, including AI calls, file operations, scripting (
SCRIPT), date/time, JSON, and more. - The Data Extractor UI — the easiest way to configure extraction.
Choose the spreadsheet when:
- You're prototyping an extraction or AI workflow.
- The job runs on demand, not on a trigger.
- The data lives in one or two sheets and doesn't need to fan out across the org.
The workflow builder
Workflows are visual pipelines. A trigger fires (a file appears, an email arrives, a schedule hits, an HTTP request comes in), and the workflow processes the resulting data step by step until it lands somewhere — back in a sheet, in an external system, in a Slack channel, or in someone's inbox.
What lives here:
- Triggers — Manual, Scheduled, Google Drive, OneDrive, Lido Mailbox, Outlook, Webhook.
- Data Operations — Get Table, Insert Rows, Update Cell, Edit Table Column, Data Extractor, Document Classifier, Smart Lookup, Edit Spreadsheet.
- Transformations — Edit Item, Aggregate, Split, Merge, Limit, Sort, JS Code, Sheet Calc.
- Flow Control — If, Filter, Switch, Error Catcher, Workflow Result.
- External Services — API Request, Prompt AI, Send Gmail, Send Slack, Send SMS, Google Drive, OneDrive.
- File Operations — Export to Excel, Export to CSV, Export as File, Copy File, Rename File, Excel to PDF, OCR PDF, Combine PDFs, Split File.
- Templates & Forms — Template Filler, PDF Form Filler.
Choose a workflow when:
- The work happens on its own — a file lands, a schedule hits, a webhook fires.
- Multiple steps need to chain together.
- You need branching, error handling, or retries.
- The output goes to multiple places (a sheet AND Slack AND email).
Every workflow node has both Parameters (what the node does) and Settings (how it executes — batch size, error handling). Every node has an error output that you can route to handle failures.
The API
The API is for situations where Lido itself isn't where the user starts. The user is in your app, your backend, or another tool, and you want extraction to happen from there.
What lives here:
POST /extract-file-data— submit a document plus a column list, get back a job ID.GET /job-result/{jobId}— poll for the extracted data.- API keys at sheets.lido.app/settings/api-keys.
Choose the API when:
- Your end users never log into Lido.
- You want extraction embedded inside another product or backend service.
- You want the same Lido extraction quality without users learning a new tool.
The most important rule with the API: build and test the configuration in the spreadsheet UI first, then click the API button to copy the JSON config. Don't write the config from scratch; you'll waste hours tuning what the UI tunes for you in minutes.
How they fit together
The same extraction configuration can live in all three surfaces:
Spreadsheet UI ← designed & tested here
│
├─→ Workflow (Data Extractor node points to this worksheet)
│
└─→ API (extractor JSON config copied via "API button")
Change the configuration in the spreadsheet and all three update. Don't maintain three copies of the same extraction logic.
Worked example: same job, three surfaces
You want to extract data from invoices. Here's how each surface looks:
Spreadsheet: open the Data Extractor, upload an invoice, list your columns, click Extract. Fast and visual. Right answer when you have a stack of 10 PDFs to process by hand.
Workflow: Google Drive Trigger → Data Extractor (pointing at the same configuration) → Insert Rows → Send Slack. Right answer when invoices arrive on their own and you want zero-touch processing.
API: your AP system sends a POST /extract-file-data request with the same column list. Right answer when your AP team uses your in-house portal, not Lido directly.
Common mistakes
- Building extraction in the API first. You'll spend hours tuning column names blindly. Build it in the spreadsheet UI first, copy the config.
- Building a workflow before testing in the spreadsheet. If extraction doesn't work well on a single test file, it won't work well on 1,000 of them.
- Using the spreadsheet for high-volume production work. If you're processing more than a few files a day, move to a workflow. The spreadsheet UI is for design; workflows are for production.
- Maintaining the same configuration in two places. Pick one canonical extractor worksheet and reference it from everywhere.
Related articles
- What is Lido?
- Quickstart: extract data from your first document
- Build your first workflow
- Triggers: how workflows start
- Lido API: quickstart and authentication
- Tables: how columns work
- Actions: how spreadsheet automation works
Updated on: 16/04/2026
Thank you!