offline / test (push) Waiting to run

Details

Wire zappier-edge into the live stack and add billing department APIs

Fleet now spawns the real zappier and middleware processes. Metered
timestamp/receipt/hash calls proxy to middleware when ZAPPIER_UPSTREAM
is set. CS credits, sales per-customer pricing, and QuickBooks export
are separate repos plugged into zappier-edge admin.

2026-09-11 15:15:55 -04:00

1.5 KiB

Raw Blame History

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)
                          --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).

1.5 KiB Raw Blame History

Composition: zappier commercial edge + Verae adapter

Ownership

1.5 KiB

Raw Blame History