Some checks are pending
offline / test (push) Waiting to run
Each module has SUMMARY.md and NATS.md (who sends/receives, subject addresses, payload). Tests: splitter 3, worm 3, aggregator 2. Forgejo repos pushed separately; this commit keeps them in the monorepo.
1.5 KiB
1.5 KiB
Composition: zappier commercial edge + Verae adapter
Users → Zapier UI
Zapier cloud runs packages/verae-zapier
--HTTPS, x-api-key--> packages/zappier /v1/*
(meter, quote, 401/403, usage)
--internal HTTPS--> packages/verae-zapier-middleware /zapier/v1/*
--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).