@myapihq/cli 2.7.0 → 2.7.2

package/dist/skills/my-auth-api/SKILL.md

@@ -4,7 +4,7 @@ version: 1.0.0
 description: >
   Add authentication to apps you build on MyAPI — a managed OIDC identity provider for your app's END USERS (à la Kinde/Auth0). One auth tenant per org; register OIDC clients; sign users in with managed Google or the hosted login page; verify RS256 tokens against the tenant JWKS.
 triggers: [auth, authentication, login, sign-in, oidc, oauth, jwt, jwks, sso, google sign-in, user accounts, identity provider, kinde, auth0, clerk]
-checksum: sha256-b5eca82bb59647677fdb5796778329160572598ac6914887768fd33529cdfe84
+checksum: sha256-5eeacc463d7323f85a330639b7073f735ccc80bddfb8217c9c15c56989b8a99a
 ---
 
 # MyAuthAPI
@@ -114,4 +114,11 @@ myapi auth client list
   `http://localhost…` for local dev).
 - `402 INSUFFICIENT_FUNDS` = empty wallet → `myapi billing topup <amount>` (or keep it funded automatically: `myapi billing auto-recharge set`). `402 SPEND_CAP_EXCEEDED` = you hit your account spend ceiling → raise it with `myapi billing spend-cap`.
 
+## Anonymous accounts
+
+`myapi account setup --anonymous` skips registration and creates an account
+with no email — for throwaway or machine-owned orgs. It cannot receive
+password resets or magic links, so attach a real identity before anything
+depends on it. `myapi status` shows `Type: anonymous`.
+
 **End-to-end example:** `examples/authenticated-app/` walks the full seam — hosted login → token verification → per-user KV record → deployed container — including the parts that cost real users hours (verify the id_token for identity; the access token is a bearer credential for `<issuer>/userinfo`).

package/dist/skills/my-company-api/SKILL.md

@@ -4,7 +4,7 @@ version: 1.0.0
 description: >
   Company database backed by the Goldfox crawl. Filter companies by Goldfox confidence tier, country/TLD consistency, behavioral page signals (has_careers_page, has_investors_page, has_shop_page, has_c_level, has_decision_maker), legal-entity status, headcount, and source-URL count. Account-based targeting and B2B firmographics.
 triggers: [companies, accounts, firmographics, abm, search, filter, goldfox, careers signal, investors, c-level, shop, b2b targeting]
-checksum: sha256-67dd4b65a9b0cc7acf7c1e4262bc66d2b58ff11ed227a24299924e0b620712f0
+checksum: sha256-4754de8a66bf13e7e2f2a23acc407ccec147e142abf8adc670ae7962ca860a74
 ---
 
 # MyCompanyAPI
@@ -90,7 +90,7 @@ myapi company get auroracloud.com --include-people 5
 ```bash
 # Save filter as audience (companies)
 AID=$(myapi audience create "EU growth-stage SaaS" \
-  --source company \
+  --from company \
   --filter '{"country":["DE","FR","GB","NL"],"has_careers_page":true,"has_decision_maker":true,"min_source_count":3}' \
   --json | jq -r .id)
 
@@ -105,6 +105,6 @@ myapi audience members $AID --limit 50 --json > accounts.json
 - `seniority`, `email_type`, and `min_link_confidence` are people-only — passing them on company search is silently ignored.
 - `include_people` only works on company search/get; people-source already embeds company by default.
 - `keyword` is a substring match on the company's **domain** — use `--keyword stripe` to find domains containing "stripe".
-- For a persistent account list, use `my-audience-api` with `--source company`.
+- For a persistent account list, use `my-audience-api` with `--from company`.
 
 Run `myapi company --help` for full flag reference.

package/dist/skills/my-container-api/SKILL.md

@@ -4,7 +4,7 @@ version: 1.0.0
 description: >
   Run containers on demand — long-running services, background workers, and scheduled jobs. The heavier-duty sibling of edge functions, for native deps and long execution.
 triggers: [container, cloud run, dynamic app, custom domain app, service, worker, scheduled job, deploy container, docker image]
-checksum: sha256-4847ab675fa971bbd0fdd83f0039d9110ba4c38e406860fe9265dd540b7f299e
+checksum: sha256-47eda6baa9055dadbd3e9d04df9fc425f1a7e96a9cd80c971c4951b97f1e94ff
 ---
 
 # MyContainerAPI
@@ -16,25 +16,33 @@ A container runs a pre-built image on managed cloud infrastructure. Three types:
 The lifecycle is **create → deploy → (optionally) bind a custom domain**.
 
 - `create` registers the container and issues a **scoped API key**, returned once. The running container receives it as the `MYAPI_KEY` env var, so your code calls other MyAPI slots with no token handling. Deploy rotates this key.
-- `deploy` ships a pre-built image reference to the runtime and makes the container live at a generated URL.
+- `deploy` takes **either** a pre-built image reference **or** a source
+  directory. `--source ./dir` tars the directory, builds it server-side
+  (typically ~4 minutes) and deploys the result — **no Docker on your machine,
+  no registry account, no image to push**. If you can write a Dockerfile you
+  can deploy; you do not need to be able to run one.
 - `domain` puts the container on a **custom domain** — how you serve a dynamic app at `app.yourbrand.com`.
 
-### Deploying safely
+### Deploying safely — NOT YET POSSIBLE ON THIS PLATFORM
 
-A deploy takes 100% of traffic the moment it lands, so a broken build is live
-before you can look at it. Two ways to avoid that:
+A deploy takes 100% of traffic the moment it lands. There is no dry run, no
+definition of correct beyond "something is listening on the port", and no way
+back. Plan for that.
 
-- `--smoke 'GET / contains assets/'` — the platform deploys the revision with
-  NO traffic, runs the assertion, and promotes only if it holds. A failure
-  leaves the previous revision serving. **Assert on content, not status**:
-  "returns 200" is true of a placeholder page too.
-- `--no-promote` — build the revision and hold it back. You get a URL to
-  exercise it, then `myapi container promote <id> <revision>`.
+`--no-promote` and `--smoke` exist as flags and **the CLI refuses them**: they
+shipped before the platform could honour them, and a guard that silently
+passes is worse than no guard. `--health-check` is accepted at create but does
+not appear on the container afterwards, so do not rely on it either.
 
-`--health-check /livez` at create time makes the startup probe an HTTP request
-instead of a bare TCP connect. `/healthz` is refused: the runtime intercepts
-it, so the probe would never reach your container and would report success
-regardless.
+Until they work, the only safe sequence is:
+
+1. deploy to a **non-production** container
+2. verify it yourself — `curl` for a string only a real build emits, not just
+   a 200, because a broken build returns 200 too
+3. deploy the same image to production
+
+`myapi container promote <id> <revision>` currently fails, so a bad deploy
+must be fixed by deploying forward. Keep a known-good image reference to hand.
 
 ### Custom domains (dynamic apps)
 
@@ -53,7 +61,7 @@ Get it right:
 | Command | What it does |
 |---|---|
 | `myapi container create --name <name> [--type service\|worker\|job] [--cron <expr>] [--cpu <n>] [--memory <size>] [--port <n>] [--env K=V,...]` | Register a container, get its scoped API key (once) |
-| `myapi container deploy <id> <image-ref> [--no-promote] [--smoke '<assertion>']` | Ship a pre-built image (rotates the scoped key) |
+| `myapi container deploy <id> <image-ref> [--no-promote] [--smoke '<assertion>']` | Ship a pre-built image (rotates the scoped API key) |
 | `myapi container revisions <id>` | List revisions and the traffic each takes |
 | `myapi container promote <id> <revision>` | Move all traffic to a revision (seconds, no rebuild) |
 | `myapi container list` | List containers in your org |
@@ -66,25 +74,23 @@ Get it right:
 ## Examples
 <!-- llm:start -->
 ```bash
-# 1. Register a service container. --health-check makes the startup probe an
-#    HTTP request instead of a bare TCP connect.
-myapi container create --name api --type service --port 8080 --health-check /livez
+# 1. Register a service container
+myapi container create --name api --type service --port 8080
 # → prints a scoped API key ONCE — save it if your code needs it
 
-# 2a. Deploy. Plain form takes 100% of traffic immediately.
+# 2a. Deploy from source — MyAPI builds it. No local Docker required.
+#     Takes ~4 minutes; the CLI polls until it is live.
+myapi container deploy <id> --source ./my-app
+
+# 2b. Or ship an image you already built and pushed.
 myapi container deploy <id> registry.example.com/my-app:v1
 
-# 2b. SAFER: assert before any traffic moves. The revision is deployed with no
-#     traffic, checked, and promoted only if the check holds. Assert on
-#     CONTENT — a broken build still returns 200.
-myapi container deploy <id> registry.example.com/my-app:v1 \
-  --smoke 'GET / contains assets/'
+# Either way this takes 100% of traffic immediately — there is no staging
+# step, so verify on a non-production container FIRST.
 
-# 2c. Or hold it back and look yourself.
-myapi container deploy <id> registry.example.com/my-app:v1 --no-promote
-# → prints a revision URL serving 0% of traffic
-myapi container revisions <id>
-myapi container promote <id> <revision>
+# 3. Check what you actually shipped. Assert on content: a build whose
+#    frontend never bundled still binds its port and returns 200.
+curl -s https://<your-domain>/ | grep -q 'assets/' || echo "BROKEN BUILD"
 
 # 3. Serve it on a custom domain. The parent domain must already be
 #    registered: myapi domain register synthesisdaily.com
@@ -118,6 +124,13 @@ way that looks like an application bug.
   `create` and cannot be changed by `deploy`.** Passing them to `deploy` does
   nothing. Recreate the container to change them.
 
+### Keeping a service warm
+
+`--min-instances 1` at create stops a `service` scaling to zero, which removes
+cold starts at the cost of running continuously. Leave it at the default `0`
+unless latency on the first request actually matters — a scaled-to-zero
+service costs nothing while idle.
+
 ## Notes
 
 - The scoped API key is shown **once** at create, and again (rotated) on every deploy. Save it if your code needs it.
@@ -126,6 +139,10 @@ way that looks like an application bug.
   the same stream and share the `--tail` budget, so raise `--tail` with it.
 - Custom domains need a deployed container **and** a MyAPI-registered parent domain — see `my-domain-api`.
 - Containers are for dynamic apps and native deps. For static sites use `my-funnel-api`; for edge functions use `my-function-api`.
+- **`--source` does not honour `.dockerignore`.** It tars the directory as-is,
+  so a `node_modules` can push the context past the limit and fail as
+  `invalid_json_response`. Build the tarball yourself and pass
+  `--source ctx.tar.gz`, or keep the directory clean.
 
 Run `myapi container --help` for the full flag reference.
 

package/dist/skills/my-crm-api/SKILL.md

@@ -4,7 +4,7 @@ version: 1.0.0
 description: >
   The canonical store of engaged contacts + companies for an org. Auto-ingests from inbound webhooks via a configurable dot-path. Fixed lifecycle_stage enum (cold | warm | qualified | customer | churned). Append-only event timeline with reserved kinds. Soft delete + restore. Promote-from-Goldfox closes the discovery → engagement loop.
 triggers: [crm, contact, company, lead, engagement, pipeline, lifecycle, qualified, customer, webhook ingest, promote]
-checksum: sha256-50cbdd28ed2a901b7a75f1a6c1df1c225d256a8d281ad86cf1e3b42511edc2fe
+checksum: sha256-dfadb20670d9d978503549d330c2c9717fbe6d13ac35b53d9e1a8874d2136fde
 ---
 
 # MyCRMAPI
@@ -38,7 +38,7 @@ Move stage with `myapi crm contacts update <id> --stage qualified`. Every stage
 goldfox | email | pixel | webhook | manual
 ```
 
-Set automatically from how the contact entered. Filter with `--source manual` (added by hand) vs `--source goldfox` (from outreach).
+Set automatically from how the contact entered. Filter with `--origin manual` (added by hand) vs `--origin goldfox` (from outreach).
 
 ### Event timeline — reserved kinds
 
@@ -75,7 +75,7 @@ A contact promoted from Goldfox carries a `goldfox_person_id`. In v2 the GET res
 
 ### Search filter — re-engagement semantics
 
-`--max-last-engagement-days N` returns contacts last engaged *more than* N days ago, and intentionally **includes contacts with no engagement at all** (promoted-but-never-emailed Goldfox leads) — the natural targets of a re-engagement campaign. To separate "never tried" from "tried and went cold," layer `--source goldfox` or post-filter the JSON.
+`--max-last-engagement-days N` returns contacts last engaged *more than* N days ago, and intentionally **includes contacts with no engagement at all** (promoted-but-never-emailed Goldfox leads) — the natural targets of a re-engagement campaign. To separate "never tried" from "tried and went cold," layer `--origin goldfox` or post-filter the JSON.
 
 ### Failure modes
 
@@ -92,7 +92,7 @@ A contact promoted from Goldfox carries a `goldfox_person_id`. In v2 the GET res
 | Command | What it does |
 |---|---|
 | `myapi crm contacts list [--limit N] [--offset N]` | List all contacts (newest engagement first) |
-| `myapi crm contacts search [--stage ...] [--source ...] [--email ...] [--min/max-last-engagement-days N]` | Filter contacts |
+| `myapi crm contacts search [--stage ...] [--origin ...] [--email ...] [--min/max-last-engagement-days N]` | Filter contacts |
 | `myapi crm contacts create <email> [--first-name ...] [--last-name ...] [--stage ...] [--custom-json ...]` | Manually create (source='manual') |
 | `myapi crm contacts get <id>` | Fetch one contact (with embedded Goldfox enrichment when available) |
 | `myapi crm contacts update <id> [--stage ...] [...]` | Patch fields. Stage change emits `stage_changed` event |
@@ -138,7 +138,7 @@ myapi crm contacts update <id> --stage customer
 myapi crm contacts events <id>
 
 # What landed in CRM from this Stripe webhook?
-myapi crm contacts search --source webhook --json \
+myapi crm contacts search --origin webhook --json \
   | jq '.contacts[] | {email, last_engagement_at}'
 ```
 
@@ -151,7 +151,7 @@ URL=$(echo "$WH" | jq -r .url)
 echo "Point Stripe at: $URL"
 
 # Later, after Stripe fires...
-myapi crm contacts search --source webhook --email "$STRIPE_CUSTOMER_EMAIL"
+myapi crm contacts search --origin webhook --email "$STRIPE_CUSTOMER_EMAIL"
 myapi crm contacts events <id> --kind webhook_received
 ```
 <!-- llm:end -->

package/dist/skills/my-database-api/README.md

@@ -15,7 +15,7 @@ Per-org KV store with namespaces. JSON values up to 256 KB per key. Compare-and-
 myapi database create my-app
 myapi database set users '{"alice":{"plan":"pro"}}' --ns my-app
 myapi database get users --ns my-app
-myapi database keys --ns my-app --values
+myapi database entries --ns my-app --values
 ```
 
 ## Authentication

package/dist/skills/my-database-api/SKILL.md

@@ -4,7 +4,7 @@ version: 1.0.0
 description: >
   Per-org KV store with named namespaces, JSON values up to 256 KB, prefix-scan listing, and compare-and-swap via etag. The substrate for any stateful agent-built app on MyAPI — user tables, session stores, idempotency keys, per-user lookup maps.
 triggers: [database, kv, key value, namespace, store, state, etag, cas, session, idempotency]
-checksum: sha256-b66f7ebdff5bce05eaab90c6812ffc0f9ec729f6df1dc4a8bca90368406b4c21
+checksum: sha256-924071245c33bf3e43f085fbd756af003e19c990f4522f658de33f42504452d7
 ---
 
 # MyDatabaseAPI
@@ -51,7 +51,7 @@ Pass `--if-match <etag>` from a previous `get` to make `set` or `del` conditiona
 | `myapi database namespaces [--json]` | List namespaces in the org |
 | `myapi database create <name>` | Create a namespace |
 | `myapi database delete-namespace <name>` | Delete namespace AND all its keys (irreversible) |
-| `myapi database keys --ns <ns> [--prefix <p>] [--limit N] [--values] [--cursor <c>]` | List keys, optionally with inline values |
+| `myapi database entries --ns <ns> [--prefix <p>] [--limit N] [--values] [--cursor <c>]` | List keys, optionally with inline values |
 | `myapi database get <key> --ns <ns>` | Get value + etag (etag printed to stderr) |
 | `myapi database set <key> <value-json> --ns <ns> [--if-match <etag>] [--file <path>]` | Set key. CAS via --if-match |
 | `myapi database del <key> --ns <ns> [--if-match <etag>]` | Delete key. CAS via --if-match |
@@ -62,7 +62,7 @@ Pass `-` as `<value-json>` to read the value from stdin, or `--file <path>` to r
 ## Examples
 <!-- llm:start -->
 ```bash
-# Create a namespace, set a key, read it back
+# Create a namespace, set an entry, read it back
 myapi database create my-app
 myapi database set user:alice '{"plan":"pro","trial_ends":"2026-06-01"}' --ns my-app
 myapi database get user:alice --ns my-app
@@ -70,7 +70,7 @@ myapi database get user:alice --ns my-app
 # stderr: — etag=A1B2C3 · updated=2026-05-12T17:00:00Z
 
 # List keys with a prefix
-myapi database keys --ns my-app --prefix user: --values
+myapi database entries --ns my-app --prefix user: --values
 
 # Compare-and-swap update
 ETAG=$(myapi database get user:alice --ns my-app --json | jq -r .etag)
@@ -104,6 +104,27 @@ myapi database get "by-email:$EMAIL" --ns users --json | jq -r .value
 - **Eventual `key_count`.** The `keys` field on a namespace is approximate; don't use it for strict pagination math.
 - **Free in v1.** Metered later if usage shows a need. Cost discipline still applies — store data, not blobs.
 
+
+## Calling this from deployed code (HTTP)
+
+The CLI is not what runs in production — a deployed function or container calls
+the HTTP API directly. That surface was previously only discoverable by
+grepping the CLI bundle, which cost one team an hour per slot.
+
+```
+base    https://api.myapihq.com
+path    /database/orgs/{org_id}/namespaces/{ns}/keys/{key}
+auth    Authorization: Bearer <api key>
+        (inside a function: env.__MYAPI_KEY · inside a container: env.MYAPI_KEY)
+body    writes take {"value": <json>} — the value is WRAPPED
+reply   { "success": true, "data": …, "error": null, "meta": {…} }
+        Unwrap `data`. On failure `success` is false and `error` is
+        { code, message }.
+```
+
+**The org id goes in the PATH, not a header.** There is no `X-Org-Id`.
+**Base URLs differ per slot** — do not assume one host for everything.
+
 Run `myapi database --help` for inline reference.
 
 **End-to-end example:** `examples/authenticated-app/` walks the full seam — hosted login → token verification → per-user KV record → deployed container — including the parts that cost real users hours (KV writes must be wrapped as `{"value": …}`).

package/dist/skills/my-domain-api/SKILL.md

@@ -4,7 +4,7 @@ version: 1.0.0
 description: >
   Register new domains and manage edge settings. Required before a funnel can go live on a custom URL.
 triggers: [domain, register domain, dns, custom domain, edge, cdn, security level, browser check, renew, namecheap]
-checksum: sha256-8f96d19c11c3591af71e9d73b2cea6d83f40abbfa1c58c5674dbe15db02efa3c
+checksum: sha256-6a686b453528c69dcc791db409c04a514422951abf333c8feed7c614311815cb
 ---
 
 # MyDomainAPI
@@ -116,4 +116,21 @@ Set `essentially_off` + `browser-check=off` to allow AI crawlers and training bo
 - All commands default to `--org` from your saved config (set with `myapi config set-org <id>`).
 - `402 INSUFFICIENT_FUNDS` = empty wallet → `myapi billing topup <amount>` (or keep it funded automatically: `myapi billing auto-recharge set`). `402 SPEND_CAP_EXCEEDED` = you hit your account spend ceiling → raise it with `myapi billing spend-cap`.
 
+## DNS record flags
+
+```bash
+myapi domain records create <domain> --type A --name @ --content 1.2.3.4 --ttl 300
+myapi domain records create <domain> --type MX --name @ --content mx.x.com --priority 10
+myapi domain records create <domain> --type CNAME --name app --content x.com --proxied
+```
+
+- `--ttl <n>` — seconds; default `1` meaning "automatic". Explicit range 60–86400.
+- `--priority <n>` — MX only, and required for it (typical `10`).
+- `--proxied` — route through the edge proxy (A/AAAA/CNAME only). Off means
+  the record resolves straight to your origin, exposing its address.
+- `myapi domain assign <domain> --no-www` skips the `www` → apex redirect.
+- `--force` on assign re-points a domain already bound elsewhere. It is the
+  reassign path, so pass `--org` explicitly and check `domain list --filter all`
+  first.
+
 Run `myapi domain --help` or `myapi domain <subcommand> --help` for full flag reference.

package/dist/skills/my-email-api/SKILL.md

@@ -4,7 +4,7 @@ version: 1.0.0
 description: >
   Send transactional and bulk email from your own domain. Create mailboxes, send/receive messages, generate AI templates, and manage warmup.
 triggers: [email, mailbox, send email, transactional email, template, warmup, inbox, outbox, ses, sender reputation]
-checksum: sha256-fa1eb6ee9e24935266643ceeecf7a748747b23377a0bfe256f76b71b62bd6349
+checksum: sha256-aa22381613affcff041a8d51d2acb2ba657fecefc97f4feba45958bcc11b2e06
 ---
 
 # MyEmailAPI
@@ -66,4 +66,39 @@ myapi email warmup stats --address hello@yourdomain.com
 - Sending is opt-in per mailbox. Newly-created mailboxes can receive but not send until `activate-sending` runs.
 - Templates are org-scoped. Set a default org once: `myapi config set-org <id>`.
 
+
+## Which name mail actually lives on
+
+Two things that read as contradictory and are not:
+
+- **Mailbox addresses are on the APEX** — `contact@yourdomain.com`, never
+  `contact@mail.yourdomain.com`. `mail.<domain>` is the *sending identity* that
+  `myapi domain email-setup` provisions, not a mailbox namespace. Creating a
+  mailbox on the subdomain fails with `DOMAIN_NOT_OWNED`.
+- **Registration and assign put `MX`, `SPF` and `DMARC` on the apex** whether or
+  not you run `email-setup`. So "apex is never touched" — which describes
+  `email-setup` specifically — is not true of the domain as a whole. If you plan
+  to run Google Workspace or another provider on the apex, check the existing
+  records first with `myapi domain records <domain>`.
+
+## Calling this from deployed code (HTTP)
+
+The CLI is not what runs in production — a deployed function or container calls
+the HTTP API directly. That surface was previously only discoverable by
+grepping the CLI bundle, which cost one team an hour per slot.
+
+```
+base    https://api.myemailapi.com   ← not the gateway
+path    /email/mailboxes   ·   /email/orgs/{org_id}/messages/send
+auth    Authorization: Bearer <api key>
+        (inside a function: env.__MYAPI_KEY · inside a container: env.MYAPI_KEY)
+body    application/json
+reply   { "success": true, "data": …, "error": null, "meta": {…} }
+        Unwrap `data`. On failure `success` is false and `error` is
+        { code, message }.
+```
+
+**The org id goes in the PATH, not a header.** There is no `X-Org-Id`.
+**Base URLs differ per slot** — do not assume one host for everything.
+
 Run `myapi email --help` or `myapi email <namespace> --help` for full flag reference.

package/dist/skills/my-function-api/SKILL.md

@@ -4,7 +4,7 @@ version: 1.0.0
 description: >
   Deploy JavaScript functions to the MyAPI edge runtime. Register a function, upload a single-file JS bundle, get a live HTTP invocation URL or run it on a cron schedule. Each function gets a scoped capability key for cross-slot calls.
 triggers: [function, deploy function, edge function, serverless, cloudflare worker, cron, scoped api key, capability key, invocation url, bundle]
-checksum: sha256-610e16c931e44d43ee6ac94a32e6d852bb900cdf6f5eea61aaeae7bb95a0814e
+checksum: sha256-1ef76e07c9fb4f295b491224261b5719314f15d3645c32e6e7b443a7fdaf95c6
 ---
 
 # MyFunctionAPI
@@ -35,12 +35,12 @@ Name rules (validated client- and server-side, kept identical):
 | Command | What it does |
 |---|---|
 | `myapi fn create --name <name> [--cron <expr>] [--scope <slot>[,<slot>...]]` | Register a function record + receive scoped API key (returned once). `--scope` narrows the key's slot grants |
-| `myapi fn deploy <id> <bundle.js>` | Upload a single-file JS bundle (≤4MB) and go live; rotates the scoped key |
+| `myapi fn deploy <id> <bundle.js>` | Upload a single-file JS bundle (≤4MB) and go live; rotates the scoped API key |
 | `myapi fn env <id> <name> <value>` | Set an encrypted secret on a deployed function |
 | `myapi fn runs <id>` | List recent invocation records (status, duration, errors) |
 | `myapi fn list` | List functions in your org |
 | `myapi fn get <id>` | Inspect a function (name, trigger, invocation URL) |
-| `myapi fn delete <id>` | Soft-delete the record + revoke the scoped key |
+| `myapi fn delete <id>` | Soft-delete the record + revoke the scoped API key |
 <!-- generated:end -->
 
 ## Examples
@@ -50,9 +50,9 @@ Name rules (validated client- and server-side, kept identical):
 myapi fn create --name my-app-api
 # → Function created: fn_abc123
 #   Scoped API key (returned once — save it if you need it):
-#     hq_live_...   (scoped keys are not visually distinct from account keys)
+#     hq_live_...   (scoped API keys are not visually distinct from account keys)
 
-# Deploy a single-file JS bundle → goes live, scoped key is rotated
+# Deploy a single-file JS bundle → goes live, scoped API key is rotated
 myapi fn deploy fn_abc123 ./dist/bundle.js
 # → Deployed function fn_abc123
 #   Invocation URL:  https://fn-abc123.<...>.workers.dev
@@ -74,17 +74,44 @@ myapi fn create --name mailer --scope email,storage
 myapi fn list
 myapi fn get fn_abc123
 
-# Delete (revokes the scoped key — future calls with it return 401)
+# Delete (revokes the scoped API key — future calls with it return 401)
 myapi fn delete fn_abc123
 ```
 
-### Using the scoped key
+### The scoped API key is already in your function — as `__MYAPI_KEY`
+
+**Two leading underscores, and it is injected for you.** Verified by probing a
+deployed function: `Object.keys(env)` returns exactly `["__MYAPI_KEY"]`, and
+`MYAPI_KEY` (no underscores) is NOT present.
+
+```js
+export default {
+  async fetch(request, env) {
+    const r = await fetch('https://api.myapihq.com/database/orgs/<org>/namespaces/app/keys/x', {
+      headers: { Authorization: `Bearer ${env.__MYAPI_KEY}` },
+    });
+    return new Response(await r.text());
+  },
+};
+```
+
+**Do not capture the key printed at `fn create` and set it yourself.** Every
+`fn deploy` rotates it, so a manually-set copy goes stale on the next deploy
+and the function starts returning 502 with nothing in the deploy output to
+explain it. The injected `__MYAPI_KEY` is always current.
+
+Note the name differs from containers, which receive `MYAPI_KEY` without the
+underscores. Both verified 2026-07-28.
+
+### Using the scoped API key
 
 ```bash
-# Save the key returned at create/deploy time
+# You do NOT need this — env.__MYAPI_KEY is injected and always current.
+# Shown only for calling the function's slots from OUTSIDE the function.
+# Save the API key returned at create/deploy time
 SCOPED_KEY="hq_live_..."
 
-# Call slots the key was granted — works (within its org + grants)
+# Call slots the API key was granted — works (within its org + grants)
 curl -H "Authorization: Bearer $SCOPED_KEY" \
   https://api.myapihq.com/database/orgs/$ORG_ID/namespaces
 
@@ -99,6 +126,7 @@ curl -H "Authorization: Bearer $SCOPED_KEY" \
 
 - The bundle is a **single JavaScript file** (≤4MB). Bundle your dependencies before deploy (esbuild/rollup/etc.).
 - `--cron` is set at create time; the trigger type is fixed for the function's lifetime.
-- Deploy rotates the scoped key on every call — re-capture the printed value if other systems use it.
+- Deploy rotates the scoped API key on every call — re-capture the printed value if other systems use it.
+- `myapi fn env <id> --set KEY=VALUE,OTHER=VALUE` sets several secrets in one call instead of one command each.
 
 Run `myapi fn --help` or `myapi fn <subcommand> --help` for full flag reference.

package/dist/skills/my-funnel-api/SKILL.md

@@ -4,7 +4,7 @@ version: 1.0.0
 description: >
   Create and publish websites (funnels) to the edge. Push raw HTML to any slug and it goes live instantly on your org's domain or preview subdomain.
 triggers: [funnel, landing page, website, page, publish, push, slug, html, edge, preview subdomain, makeautonomous]
-checksum: sha256-3b463d6ac52fba7d44f89195b5704b02903ffdd9a677655f9c1bff0f13b25ab4
+checksum: sha256-849afbb7c2c60ea88c3476d50bf51289b77cedc819a0c2b69787075ff9c23b4b
 ---
 
 # MyFunnelAPI
@@ -33,7 +33,7 @@ Every funnel auto-provisions a **webhook** at creation (`org_webhook_id`), and e
 | `myapi funnel push [slug]` | Push HTML from stdin to a slug (default: `/`). **Overwrites** an existing page — refused without `--force`. `--json` prints `{slug, subdomain_url, overwritten, org_id, funnel_id}` |
 | `myapi funnel publish <dir>` | Upload a whole directory as the funnel's site (`--env dev\|prod`, default prod; `--api-fn <id>`; `--json`). Prod refuses to replace a live site without `--force` |
 | `myapi funnel pages [funnel_id]` | List the pages currently published to a funnel |
-| `myapi funnel form [funnel_id]` | Emit canonical form HTML (and register a binding with `--capture-to`) |
+| `myapi funnel form [funnel_id]` | Emit canonical form HTML (`--capture-to`, `--cta`, `--success`, `--honeypot`) |
 | `myapi funnel verify [slug]` | Verify a published page is reachable + check links/webhooks |
 <!-- generated:end -->
 
@@ -83,7 +83,10 @@ Zero-config form (the happy path most agents want) — still pin the org + funne
 
 ```bash
 myapi funnel create --name acme-demo --org <org_id>
-myapi funnel form --slug join --fields email:required,name --funnel <funnel_id> > snippet.html
+myapi funnel form --slug join --fields email:required,name --funnel <funnel_id> \
+  --cta "Join" --success "Thanks — check your inbox." --honeypot company_url > snippet.html
+# --honeypot names a hidden field: bots fill it, humans never do, so a
+# submission carrying it is dropped.
 # paste snippet.html into your page (or pipe through funnel push):
 cat page-with-snippet.html | myapi funnel push / --funnel <funnel_id>
 # Submissions land in the funnel's auto-provisioned webhook → CRM upsert on `email` → any bound workflow fires.

package/dist/skills/my-git-api/SKILL.md

@@ -4,7 +4,7 @@ version: 1.0.0
 description: >
   Hosted git repositories over HTTP. Create repos, read history (log/show/tree/blob/diff), and write atomically (commit/branch/tag/merge) — no clone needed. Real `git clone`/`push` also work over HTTPS with your API key as the password.
 triggers: [git, repo, repository, clone, push, commit, branch, tag, merge, diff, version control, source control, vcs]
-checksum: sha256-a059c8f2b59205a1d66ecf70556b60fa3a3606044aaa54e242344ea652efb5e9
+checksum: sha256-417bafc3e56707f637937f98341d6200c8a9bb6ad5d0b13f84f7b6810e0340f5
 ---
 
 # MyGitAPI
@@ -90,7 +90,7 @@ myapi git delete-branch my-app feature
 ### Clone & push with real git
 Hosted repos speak the real git smart-HTTP protocol. Clone, fetch, and push
 over HTTPS with **HTTP Basic auth — your MyAPI API key is the password**, any
-username works (git accepts the key in either field).
+username works (git accepts the API key in either field).
 
 ```bash
 # URL: https://git.mygitapi.com/<org-slug>/<repo>.git
@@ -100,7 +100,7 @@ username works (git accepts the key in either field).
 # Clone (key as password; "x" is a throwaway username)
 git clone https://x:$MYAPI_KEY@git.mygitapi.com/my-org-slug/my-app.git
 
-# Or set the remote and let git prompt for the password (paste the key)
+# Or set the remote and let git prompt for the password (paste the API key)
 git remote add origin https://git.mygitapi.com/my-org-slug/my-app.git
 git push origin main
 ```
@@ -117,6 +117,12 @@ surface never leaks which repos exist).
 - **`commit --base`** is the concurrency guard: pass the expected tip SHA to reject a stale write, or `--base ""` to require the branch be newly created. Omit it to create-or-update.
 - **Metering.** A `git push` (and `myapi git commit`) is metered like a commit. Clone/fetch (`upload-pack`) is free.
 - **Limits.** A push body is capped at 100 MiB; per-repo size limits apply (a push past the cap is reported as a receive-pack failure).
-- **Auth field.** git may put the key in the username or password slot — both work. Embedding it in the URL (`https://x:$KEY@…`) avoids the interactive prompt but writes the key into `.git/config`; use a credential helper for anything persistent.
+- **Auth field.** git may put the API key in the username or password slot — both work. Embedding it in the URL (`https://x:$KEY@…`) avoids the interactive prompt but writes the API key into `.git/config`; use a credential helper for anything persistent.
+
+## Commit authorship
+
+`myapi git commit … --author-name "<n>" --author-email "<e>"` sets the commit
+author. Without them the commit is attributed to the API key's account, which
+makes every agent-written commit look like the same person.
 
 Run `myapi git --help` for the full flag reference.

package/dist/skills/my-people-api/SKILL.md

@@ -4,7 +4,7 @@ version: 1.0.0
 description: >
   Contact database backed by the Goldfox crawl. Filter people by Goldfox confidence tier, seniority, email type, country, link confidence, plus rich behavioral company signals (has_c_level, has_careers_page, has_decision_maker, etc.). The targeting layer for outbound campaigns.
 triggers: [people, contacts, leads, prospects, search, filter, goldfox, decision-makers, c-level, b2b targeting, corporate email]
-checksum: sha256-a4b594a30cc06d2f40fe26c594c1cb6962d91c4dbcc0625210d45a3faa27336e
+checksum: sha256-1eb93087638966eee65fb7a88fe37baaa27a01dd5d97c1ef17387b1a36300c0e
 ---
 
 # MyPeopleAPI
@@ -88,7 +88,7 @@ myapi people get p_MTdlc2llY2xlLmZy.0
 ```bash
 # Build the target audience (saved filter)
 AID=$(myapi audience create "EU decision makers w/ careers signal" \
-  --source people \
+  --from people \
   --filter '{"seniority":["c_level","vp_director"],"country":["DE","FR","GB"],"email_type":["corporate"],"has_careers_page":true}' \
   --json | jq -r .id)
 
@@ -100,7 +100,7 @@ myapi audience members $AID --limit 100 --json > targets.json
 ## Notes
 
 - The dataset is the Goldfox crawl — multi-million-row corporate contact data with provenance signals. Filter quality matters: defaults to `confidence=high` gives 96.4% of rows by count, but it's the curated tier; widening with `confidence=low` brings UGC rows that need spot-checking.
-- `seniority`, `email_type`, and `min_link_confidence` are people-only — silently ignored on `my-company-api` and on audiences with `--source company`.
+- `seniority`, `email_type`, and `min_link_confidence` are people-only — silently ignored on `my-company-api` and on audiences with `--from company`.
 - `keyword` matches the row's **domain**, not name/title. Use `--keyword acme` to find people whose domain contains "acme".
 - For a persistent target list, use `my-audience-api` (snapshot the filter; re-evaluate on `audience refresh`).
 

package/dist/skills/my-pixel-api/SKILL.md

@@ -4,7 +4,7 @@ version: 1.0.0
 description: >
   Tracking pixel + identity resolution for MyAPI funnels and email. Capture visits and events, resolve known users to anonymous sessions, stream interaction events for analytics. Pairs with mycrmapi for auto-ingest of pixel_visit events on known contacts.
 triggers: [pixel, analytics, tracking, visit, event, identity, session, attribution, geo, open pixel]
-checksum: sha256-1e8284fbf546ad1bdff32790f56f8c524a19e0b80b92cc6d612ce15295632c9f
+checksum: sha256-562f081ef28c0dae01045a4135f9d073d69c50899145e75c6c97fe75b974cb15
 ---
 
 # MyPixelAPI
@@ -83,6 +83,17 @@ myapi pixel audience
 - **No write API for synthetic events** — the pixel records what the embedded JS/email-pixel observes. To inject custom timeline entries, use `myapi crm contacts/{id}/events` instead (when reserved-kind allows; today event writes are platform-only).
 - **`my-crm-api` is the durable record.** Pixel data ages out at ~90 days; CRM events are permanent. If a behavioral signal matters for long-term targeting, promote it into the CRM.
 
+## Linking a known identity
+
+`myapi pixel identify <pixel_id>` attaches a known identity to an anonymous
+visitor:
+
+- `--email <addr>` — the address to link.
+- `--external-id <id>` — your own user id, for joining back to your database.
+
+Pass either or both. After this, `pixel identity <pixel_id>` resolves the
+graph across the visitor's sessions.
+
 Run `myapi pixel --help` for inline reference.
 
 ## Status