Metadata-Version: 2.4
Name: autotouch-cli
Version: 0.2.87
Summary: Autotouch Smart Table CLI
Project-URL: Homepage, https://app.autotouch.ai
Project-URL: Documentation, https://github.com/nicolonic/autotouch_main/tree/main/docs/research-table/reference
Project-URL: Source, https://github.com/nicolonic/autotouch_main
Keywords: autotouch,smart-table,cli,automation,api
Classifier: Development Status :: 4 - Beta
Classifier: Environment :: Console
Classifier: Intended Audience :: Developers
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.9
Classifier: Programming Language :: Python :: 3.10
Classifier: Programming Language :: Python :: 3.11
Classifier: Programming Language :: Python :: 3.12
Classifier: Topic :: Software Development :: Libraries :: Python Modules
Classifier: Topic :: Utilities
Requires-Python: >=3.9
Description-Content-Type: text/markdown
Requires-Dist: requests>=2.31.0
Requires-Dist: python-dotenv>=1.0.0
Provides-Extra: mongo
Requires-Dist: pymongo>=4.7; extra == "mongo"

# Autotouch CLI

Installable CLI for the Smart Table developer API.

Use it when you want command-driven access to search, tables, columns, runs, jobs, leads, sequences, and task workflows without hand-writing raw HTTP requests.

The CLI talks to the same API the product uses. For automation, prefer `--output json`.

For a machine-readable local command contract, use `autotouch cli-manifest --output json`.
For a shipped human-readable reference generated from the installed parser, use `autotouch cli-reference`.

## Install

```bash
pipx install autotouch-cli
# or
pip install autotouch-cli
# upgrade
pip install -U autotouch-cli
```

## First Run

Existing developer key:

```bash
read -s AUTOTOUCH_API_KEY
export AUTOTOUCH_API_KEY
autotouch setup --api-key "$AUTOTOUCH_API_KEY" --base-url https://app.autotouch.ai
```

Equivalent manual steps:

```bash
autotouch auth set-key --api-key "$AUTOTOUCH_API_KEY" --base-url https://app.autotouch.ai
autotouch auth check --base-url https://app.autotouch.ai
```

Fresh account:

```bash
export AUTOTOUCH_CONFIG_PATH=/tmp/autotouch-audit.json
read -s AUTOTOUCH_BOOTSTRAP_PASSWORD
export AUTOTOUCH_BOOTSTRAP_PASSWORD

autotouch auth bootstrap \
  --first-name Ada \
  --last-name Lovelace \
  --email ada+audit@example.com \
  --password "$AUTOTOUCH_BOOTSTRAP_PASSWORD" \
  --organization-name "Audit Org" \
  --save-key

autotouch auth check
```

Config precedence:
- Explicit flags win over environment variables.
- Environment variables win over saved config.
- Saved config wins over built-in defaults.
- For JSON payload inputs, pass either `--data-json` or `--data-file`, not both.

## 5-Minute Flow

```bash
# 0) First-run setup
autotouch setup --api-key "$AUTOTOUCH_API_KEY" --base-url https://app.autotouch.ai

# 1) Inspect machine-readable contract
autotouch capabilities --output json

# 2) Create a table and capture its id
TABLE_ID=$(autotouch tables create --name "CLI Contacts" --output json --select id)

# 3) Add a couple rows with the default lead_finder recipe's expected field
ROW_ID=$(autotouch rows add \
  --table-id "$TABLE_ID" \
  --records-json '[{"domain":"openai.com","companyName":"OpenAI"},{"domain":"stripe.com","companyName":"Stripe"}]' \
  --output json --select rowIds.0)

# 4) Generate a provider-backed column payload
autotouch columns recipe --type lead_finder --out-file column.json

# 5) Create the column and capture its id
COLUMN_ID=$(autotouch columns create --table-id "$TABLE_ID" --data-file column.json --output json --select id)

# 6) Run a small controlled slice and capture the bulk job id
JOB_ID=$(autotouch columns run-next \
  --table-id "$TABLE_ID" \
  --column-id "$COLUMN_ID" \
  --count 2 \
  --show-estimate \
  --wait \
  --output json --select job_id)

# 7) Verify backend truth
autotouch jobs get --job-id "$JOB_ID" --output json

# 8) Inspect exactly what changed
autotouch rows get --table-id "$TABLE_ID" --row-id "$ROW_ID" --output json
```

## Cheat Sheet

- Create table: `autotouch tables create`
- Add rows: `autotouch rows add`
- Inspect rows: `autotouch rows list`, `autotouch rows get`
- Inspect one cell: `autotouch cells get`
- Create a workflow column: `autotouch columns recipe`, `autotouch columns create`
- Run Exa Company Search for basic company discovery, competitors, and lookalikes: `autotouch search companies`, `autotouch search similar-companies`
- Inspect list-build inputs: `autotouch list-build inputs`
- Build durable company and lead lists on Smart Table workers: `autotouch list-build companies`, `autotouch list-build leads`
- Check connected LinkedIn account status/limits: `autotouch linkedin status`, `autotouch linkedin limits`
- Run controlled slices: `autotouch columns run-next`
- Poll authoritative state: `autotouch jobs get`
- Create/activate sequences: `autotouch sequences recipe`, `autotouch sequences create`, `autotouch sequences activate`
- Query leads: `autotouch leads query`
- Find a lead by email or phone: `autotouch leads query --search '<email-or-phone>' --limit 10`

## Neural Search vs Durable List Build

Autotouch has two different company/people discovery paths.

Use `autotouch search companies` for Exa Company Search when the target is basic company discovery, competitors, lookalikes, or a semantic company search. Put company constraints directly in natural language: industry, geography, funding, headcount, technology, founded date, and similarity. Examples: "AI workflow platforms for healthcare", "US education software startups focused on AI math tutoring with 1-50 employees", or "companies like Rippling for HR and workforce management". Exa company search returns up to 100 results per API call and costs 1 credit per 10 returned results.

Use `autotouch search similar-companies` as a convenience wrapper for Exa Company Search similarity. Prefer `--query` for Exa's documented semantic patterns, such as "companies like Notion", "competitors of Stripe", or "companies working on making space travel cheaper". The older seed fields `company_name`, `company_domain`, and `company_description` remain available when you want the CLI/API to compose that query; it does not use Exa `/findSimilar`.

Use `autotouch search people` for provider-hidden people search when the target is niche, semantic, or hard to express with structured filters. People search currently returns at most 10 results per API call and costs 1 credit per API call.

Use `autotouch list-build companies` and `autotouch list-build leads` for structured, repeatable LinkedIn/Sales Navigator list construction. This is the only CLI path for building LinkedIn-sourced company and lead lists. Treat list builds as the sourcing step for the Smart Table research workspace: build company/account records first by default, add the records to a research table, then enrich, score, segment, find related leads, attach signals/notes, and continue downstream workflows from that table. Use lead builds directly when the request is explicitly person/contact focused. This path uses Autotouch-managed provider access, so users do not need to connect their own LinkedIn account. Use filters like geography IDs, company size, industry IDs, title/persona, and current company IDs; call `autotouch list-build inputs` for supported values. Durable list builds run as background jobs with status/results endpoints and cost 1 credit per successful non-empty result page.

For structured company builds, start with industry IDs plus geo/company-size filters. User-supplied `keywords` are optional when structured filters are present; use them only to refine, disambiguate, or recover hard-to-classify targets instead of carrying the whole target definition.

For account-first prospecting from LinkedIn/Sales Navigator, build companies/accounts first, inspect the returned company IDs, then pass those IDs to `autotouch list-build leads --current-company-id ...`. Do not use Exa company search as a default pre-step for every LinkedIn list build; use it when the user's target is genuinely semantic, niche, competitor-based, or not meant to be LinkedIn-sourced.

## More

For automation or agent-driven setup, use:
- `autotouch cli-manifest --output json` for the local machine-readable command contract
- `autotouch cli-reference` for the shipped parser-generated reference
- `autotouch capabilities --output json` for provider/workflow contracts
- `autotouch --version` should be `0.2.87` or newer for structured company list builds without user-supplied keywords, stored list-build input lookup, research-workspace list-build guidance, the cleaned single LinkedIn-sourced list-build path, and Exa Company Search up to 100 results
- `autotouch capabilities --output json --select list_builds` for documented list-build inputs such as geography IDs, company size buckets, profile language, and company IDs
- `autotouch list-build inputs` and `autotouch list-build pricing` before creating durable list-build jobs
- `autotouch list-build companies` and `autotouch list-build leads` for durable LinkedIn-sourced company and lead list builds with Smart Table-owned background workers, visible progress, and no user-owned LinkedIn connection requirement
- `autotouch linkedin status` and `autotouch linkedin limits` for connected-account diagnostics
- `autotouch rows list` / `autotouch rows get` / `autotouch cells get` for read-back and audit
- `autotouch sequences ...` and `autotouch tasks ...` for sequence/task workflows
- `pip install 'autotouch-cli[mongo]'` if you need the Mongo-backed `status` / `watch` commands

## Realtime Table Updates

Research-table cell updates are persistence-first. Writers update Mongo `cells`; the API-side Mongo change-stream listener emits table-scoped `cells_update_batch` events. Workers should not emit per-cell socket events directly, and `/api/events/emit` is not a cell-update transport.

CSV import/export and long-running worker flows still emit low-rate lifecycle/progress events such as `table_update`, but saved cell state is the source of truth for table rendering. For the full contract, see `docs/platform/realtime-events.md` and `docs/workers/bulk-jobs.md`.

## LLM Columns

For `llm_enrichment` in `agent` mode, the recommended path is:
- provide `config.instructions`
- let the API compile the runnable prompt
- keep `config.useAutoSchema = true`

Only send `user_schema` / `response_schema` when you intentionally want to override the generated schema and keep it aligned yourself. The installed recipe surface at `autotouch columns recipe --type llm_enrichment` follows this contract.

Schema ownership rules:
- Accepted generated schemas and explicit user schemas are the saved output contract.
- Row execution must not add fields, rename fields, or replace a valid locked schema.
- Agent-mode evidence/scored state decides which values may fill the schema; the finalizer formats those values and schema validation gates persistence.

Prompt variables in authored prompts support nested JSON access:
- Use flat row variables like `{{company_name}}` for scalar columns.
- Use dotted placeholders like `{{linkedin_lookup.linkedin_url}}` when the source column stores JSON or stringified JSON.
- For arrays, use numeric indexes such as `{{contacts.0.email}}`.
- This is different from config payload mappings, which use objects like `{ "column": "linkedin_lookup", "path": "linkedin_url" }`.

## Docs

- Full CLI reference: https://github.com/nicolonic/autotouch_main/blob/main/docs/research-table/reference/autotouch-cli.md
- Agent playbook: https://github.com/nicolonic/autotouch_main/blob/main/docs/research-table/guides/autotouch-cli-agent-playbook.md
- Tables/API reference: https://github.com/nicolonic/autotouch_main/blob/main/docs/research-table/reference/tables-api.md
- Authentication/scopes: https://github.com/nicolonic/autotouch_main/blob/main/docs/platform/authentication.md
- Instantly/Smartlead external sending accounts: https://github.com/nicolonic/autotouch_main/blob/main/docs/integrations/email-automation-platforms.md
