API & CLI
The data engine, from your terminal
Everything Databar does in the UI is callable: a REST API for your product and pipelines, and a CLI and MCP server built for agents like Claude Code. Create tables, run waterfalls, export to your CRM, from code.
Python SDK
One install, and the engine is importable
pip install databar gives you the SDK and the CLI in the same package. Python 3.9 and up, MIT licensed, and every call drives the same engine as the app.
→ Typed objects back, not dicts to guess at
→ Sync when you want a result, tasks when you want to poll or cancel
→ Bulk results come back aligned to your inputs: one element each, None where nothing was found
Auth that stays out of the repo
databar login saves your key to ~/.databar/config. Or set DATABAR_API_KEY, or pass it to the client. Never in the code you commit.
Waterfalls in one call
run_waterfall_sync tries providers in sequence and stops at the first hit. The fallback logic is the platform's, not yours to maintain.
Long runs are tasks
poll_task to wait, partial to collect what has already finished, cancel to stop. Finished rows keep their results.
CLI
The same engine, without leaving the terminal
The CLI ships in the same package. Every command speaks table, JSON or CSV, so it pipes into whatever you already use.
Everything is a command
enrich, waterfall, flow, table, task. List, run, inspect and cancel without opening the app.
CSV in, CSV out
Bulk runs take an input file and write an output file. No glue script in between.
Built to pipe
JSON output is one predictable envelope: ok true with data, or ok false with an error code. Easy to test, easy to chain.
The engine you're scripting
One bulk call fills 1,204 rows and syncs them back to HubSpot. Same tables, same waterfalls, same run log you already see in the app.
Claude Code> Enrich these 1,204 accounts and sync them to HubSpot⏺ databar · run_bulk_enrichment (1,204 rows)⎿ 388 empty fields filled⎿ Synced 1,204 records to HubSpotStripeSynced
How it works
From API key to enriched table in three calls
1. Create a table
Post your rows or point a source at it: CSV, webhook, or a CRM segment.
2. Attach an enrichment
Pick any of 160+ providers or a waterfall, map the input columns, and trigger the run.
3. Pull the results
Poll the task, fetch the rows, or let an exporter push them straight to your CRM.
Safe to automate
Cost preview and branching, exposed to your code
Structured in, structured out
Tables, runs, and results are JSON with stable schemas. No scraping your own dashboard.
Price checks before big runs
The same per-step cost preview the UI shows is in the API, so a script or an agent can check the bill before enriching 10,000 rows.
Run history
Every run is a record
Debug from the terminal
Status, output, duration, and cost per step, logged for every run and queryable over the API. Your agent reads the same log you do.
Run surfaces
One engine, four ways to drive it
In a table
Build it by hand, watch it fill, then hand the same table to a script. Nothing to port.
On a schedule
Point a source at a table and let it re-sync itself. Monday at 6am, with nobody touching it.
From your code
One call from your product or your pipeline, with the Python SDK, the CLI, or plain REST.
As an agent tool
65+ tools over MCP. Claude Code, Cursor and Codex run the same enrichments whenever they need data.
