Avoca — Internal

Appearance

Avoca dev environment access reference ​

Sandy's working reference for the EAS pilot AutoOps integration. Captures where each credential lives, how to verify it, and what answer (if any) was received from Kareem during onboarding. Source-of-truth lives in Slack and Vercel; this doc is the searchable summary.

Last verified: 2026-05-01

Vercel ​

What it unlocks: Pulls every internal env var avoca-next needs to run locally — Supabase, Vapi, Hamming, Datadog API keys, Avo service token, OpenAI/Anthropic keys, etc. (211 keys total in dev as of 2026-05-01.)

Account: sandy.corsillo@avoca.ai. Member of the Avoca team (slug avoca-ai, id team_10jnr1I4wuI41DgqvZCbHADv). SAML SSO via Google.

CLI: vercel 53.0.1+ via npm global. Earlier yarn-global install was orphaned and yarn's upgrade semantics couldn't reach latest. Reinstall via npm install -g vercel@latest if it drifts.

Smoke test ​

bash
tmp_dir="$(mktemp -d)"
vercel link --cwd "$tmp_dir" --project avoca-next --scope avoca-ai --yes
vercel env pull --cwd "$tmp_dir" "$tmp_dir/web.env" --environment development --yes
wc -l "$tmp_dir/web.env"   # expect ~212
echo "TMPDIR=$tmp_dir"

Expect: a .env file with 200+ lines, no auth errors. Inspect with care — file contains plaintext secrets.

Critical env keys present in development pull ​

  • Supabase: NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY, SUPABASE_SECRET_KEY
  • Vapi: VAPI_API_KEY, VAPI_TOKEN
  • Hamming: HAMMING_API_KEY
  • Datadog: DATADOG_API_KEY, DATADOG_APP_KEY
  • Avo: AVO_APP_URL, AVO_SERVICE_TOKEN
  • LLMs: OPENAI_API_KEY, ANTHROPIC_API_KEY

Known missing from development pull ​

  • WEBHOOK_API_KEY_ENCRYPTION_KEY — not in dev. Required only for running the canonical Avoca decryption path on a local app instance (decrypts the autoops_credentials.api_key blobs in Supabase). Not needed for our test path — see AutoOps below.

Vercel MCP for Claude ​

Installed at user-global level. Provides tools: list_teams, list_projects, list_deployments, get_deployment, get_deployment_build_logs, get_runtime_logs, search_vercel_documentation, etc.

AutoOps ​

What it unlocks: Direct API calls against AutoOps's REST surface (booking, jobs, customers, availability, cancel, reschedule).

Tenant scope: Prod — there is no sandbox. The API key is for the live EAS shop. Every cancel/reschedule mutates real data.

Test loop (per Kareem): schedule a test job, grab its id from the response, then cancel/reschedule that id. Avoid touching jobs not created during testing.

Credentials ​

  • apiKey — provided by Kareem directly via Slack. Not in any env var. Stored locally in env/.env.secrets.local as AUTOOPS_API_KEY (per composable.env contract).
  • clientId = 1 for the EAS team.
  • API base URL = https://api.autoops.com/v1 (hardcoded in apps/web/lib/autoops/autoops.ts; not an env var).

Smoke test ​

bash
# Replace $AUTOOPS_API_KEY with the value from env/.env.secrets.local
curl -sS -H "Authorization: Bearer $AUTOOPS_API_KEY" \
  "https://api.autoops.com/v1/clients/1/services" | jq '.data | length'

Expect: a positive integer (count of services configured for the EAS shop). 200 OK.

Architectural decision: bypass Avoca's decryption layer for testing ​

The running Avoca app reads encrypted AutoOps credentials from Supabase (autoops_team_configs joined to autoops_credentials) and decrypts them with WEBHOOK_API_KEY_ENCRYPTION_KEY. Sandy doesn't need that path — Kareem provided the plaintext apiKey directly. Test path is direct curl against the AutoOps API + (eventually) Hamming-driven Vapi conversational tests.

This means Sandy never decrypts customer secrets locally. Cleaner from a security posture; also means we don't need the master encryption key.

Open follow-ups ​

  • AutoOps UI login — not yet provisioned. Asked for; pending. Not blocking testing, but useful for visual state inspection. Contact: Jackson Graves.

Hamming ​

What it unlocks: Conversational test runs against the EAS Vapi assistant without making real phone calls. The cleanest test path for in-call tool flows.

Account: Sandy's Hamming login is provisioned. Can manage API keys + project settings.

Project for Straight Away Auto / EAS: to confirm with Kareem — does one exist, or do I create one? Document name + project URL once known.

Smoke test ​

Log into Hamming dashboard. Locate (or create) a project for AutoOps assistant testing. Trigger a test conversation. Observe that tool calls fire and reach our handler.

Credentials ​

HAMMING_API_KEY is in the Vercel dev env pull. Programmatic API access is available via that key.

Datadog ​

What it unlocks: Searchable logs for tool execution, AutoOps API calls (egress), Inngest function runs, and post-call processing. Critical for tracing what happened when a call went through the system.

Account: Sandy logged in successfully.

API access keys: DATADOG_API_KEY + DATADOG_APP_KEY present in the Vercel dev env pull.

Smoke test ​

Log into the Datadog UI. Search for logs in the avoca-next service for a known timeframe. Confirm log results render and you can filter by service/team.

Open follow-ups ​

  • Saved views for AutoOps tool execution and per-call traces are not yet documented. Worth identifying and pinning canonical queries (e.g., "find all autoOps* tool spans for call UUID X") once we have a real call to trace.

GitHub ​

What it unlocks: Push branches and open PRs against AvocaAI/avoca-next.

Permission level: WRITE (verified via gh repo view AvocaAI/avoca-next --json viewerPermission).

Smoke test (deferred) ​

Will be exercised naturally during Plan F when we push feat/autoops-reschedule. No need to run a separate no-op-PR check pre-emptively.

Supabase ​

What it unlocks: Direct queries against the production Supabase database — assistant_configs, autoops_team_configs, call logs, etc.

Access: via the Supabase keys pulled through Vercel (NEXT_PUBLIC_SUPABASE_URL, SUPABASE_SECRET_KEY).

Smoke test ​

bash
# After loading env vars from the Vercel pull
psql "$NEXT_PUBLIC_SUPABASE_URL" -c "select count(*) from teams;"
# Or via supabase CLI / a quick TS script using @supabase/supabase-js

Expect: a positive integer.

EAS team_id ​

Discoverable via:

sql
select id, name from teams where name ilike '%EAS%' or name ilike '%express%' or name ilike '%straight%';

Documented value once retrieved: to fill on first query.

Process notes ​

  • Pattern direction for new CRM integrations: see integration-playbook.md. Centralized end-of-call webhook + per-vertical Triager + per-CRM workflow stages. Live tools live at lib/tools/<vertical>/.
  • AutoOps cancel reference: PR #9450 by kareem-avoca, merged 2026-04-26. Mostly playbook-compliant; deviates only in handler file location (lib/vapi/tools/handlers/autoOpsCancelBooking.ts vs the playbook's lib/tools/<vertical>/<tool>Tool.ts).
  • Reschedule pattern decision: open question for Plan F's ADR — mirror Kareem's location (consistency with existing AutoOps code) vs follow playbook strictly (consistency with new pattern). Decide after first reading the cancel handler in detail.
  • Deployment of assistant_configs changes — deferred ask. Will re-engage Kareem when reschedule POC is working locally and ready to ship.

Captured artifacts ​

Update log ​

  • 2026-05-01 — Initial population. Vercel, Datadog, Hamming, GitHub access verified. AutoOps prod-key gotcha noted. Encryption key dropped from concerns. Playbook captured.