dogfu 0.10.0

Internal admin/marketing CLI — discovery, enrichment, outreach, and CRM over one interface.

dogfu

Internal admin CLI + SDK for Agent Berlin staff (admin_users). One interface over LinkedIn, X, Google, ChatGPT, SEO (the dogfu data API) and the Close CRM (via the admin CRM proxy). The sibling of backend/sdk-python — same transport posture (a single Bearer token against the Berlin backend, retry with backoff, a typed exception hierarchy, config-file session), scoped to the internal admin surface instead of a customer project.

Auth

dogfu authenticates with a single session token (a short-lived JWT, 24h), minted by exchanging a one-time OTP from the dogfu MCP's get_setup_instructions:

dogfu configure --otp <OTP> --title "<what this session is for>"

This POSTs {otp, title} to /dogfucli/exchange-otp and saves the returned token to ~/.dogfu/config.json. Subsequent commands resolve the token from DOGFU_TOKEN first, then that file. There is no refresh endpoint — on an auth failure, run get_setup_instructions again for a fresh OTP and re-configure.

dogfu is not project-scoped (no --domain); access is platform-wide for staff.

Endpoints

Everything goes through the Berlin backend (https://backend.agentberlin.ai by default; override with --base-url / DOGFU_BASE_URL):

Group	Backend route
linkedin / x / google / chatgpt / seo	/api/v1/admin/dogfu/*
crm	/api/v1/admin/crm/* — allowlisted proxy to Close CRM

The CRM proxy holds the per-admin Close key server-side (configured from the admin Console), so dogfu never sees a Close credential — it forwards Close sub-paths under the dogfu session token.

Usage

dogfu --help                  # list groups
dogfu <group> --help          # list a group's commands
dogfu <group> <cmd> --help    # flags + the Output: data shape

dogfu seo domain-overview --target acme.com
dogfu crm lead create --name "Acme" --url https://acme.com

Output is canonical JSON by default (-f table for humans, -o FILE to write).

Outreach cadence

A touch is an attempt to reach a lead — touch 0 is the reach-out, 1..N are follow-ups, on whatever channel the rep used. The sequence is unbounded and only ends on reply or stop. State lives in four system-managed lead custom fields (touch_stage, last_touched, next_touch_due, touch_channel), created once by a Close admin; only the crm touch verbs write them.

dogfu crm touch due                 # the work queue: reach-outs + follow-ups owed today
dogfu crm touch record <lead_id> -c linkedin   # log a touch, roll the reminder forward
dogfu crm touch reply <lead_id>     # prospect answered: end the chase
dogfu crm touch stop  <lead_id>     # give up / nurture: end the chase
dogfu crm touch reconcile           # audit the cadence-task invariant (--fix to repair)

Every lead in the active sequence carries exactly one open cadence task — created when the lead enters the reach-out status (crm lead create/update -s Qualified), rolled forward by record, and closed on reply/stop. Because of this, two queues mean the same thing:

• crm touch due is dogfu's own queue — reach-outs (computed from status + never-touched) unioned with follow-ups whose next touch is due. Complete on its own.
• Close's native task list is the same queue rendered in Close's UI. It is only complete because the reach-out, too, is a real task; that's what lets a BDR rely on Close's Tasks/Inbox instead of the CLI.

crm touch reconcile is the backstop that keeps the two in sync: it flags (and with --fix repairs) any lead missing its task, carrying a stray or duplicate one, or whose task's due date has drifted. It reuses only existing reads, so it's safe to run on demand or on a schedule.

Programmatic use

from dogfu import Dogfu
dx = Dogfu()                                  # resolves DOGFU_TOKEN / config file
dx.seo.domain_overview(target="acme.com")     # -> DomainOverview
dx.crm.create_lead(name="Acme")

Develop

uv run python tests/smoke.py   # offline checks (normalizers, models, SDK wiring)