# Composition: zappier commercial edge + Verae adapter

```text
Users → Zapier UI
Zapier cloud runs packages/verae-zapier
  --HTTPS, x-api-key--> packages/zappier /v1/*
                          (meter, quote, 401/403, usage)
                          --ZAPPIER_UPSTREAM--> packages/verae-zapier-middleware /zapier/v1/*
CS :3011, Sales :3012, Accounting/QuickBooks :3013 --> zappier-edge admin
                                --sync--> api.veraetime.net  or MOCK_VERAE
                                --NATS--> workers --> Verae + Zapier REST Hooks

Humans → zappier /portal   signup, API key, usage, reloads, invoices
Ops    → zappier /admin    rate card, tiers, customers, PO invoices
```

## Ownership

| Concern | Package |
|---------|---------|
| API keys, custom pricing, Stripe, invoices, portal | `packages/zappier` |
| Timestamp/verify/status, NATS, REST Hooks, mock Verae | `packages/verae-zapier-middleware` |
| Zapier Platform nouns (creates/searches/triggers) | `packages/verae-zapier` |
| Official SDK reference | `vendor/zapier-platform` |

Zapier never talks to NATS or `api.veraetime.net`.

Do not reimplement Stripe, invoices, or the rate-card UI inside the Verae middleware.

Public keys are zappier `x-api-key` (issued at portal signup). Middleware `zmw_` / `PLAN_LIMITS` stay internal until composition PR 4 removes them from the public path.

Demo zappier routes `/v1/transform` and `/v1/storage` are a metering sandbox, not Verae timestamping or encrypted LTS.

Payment invoices (zappier) are not certified timestamp receipts (Verae feature i).