Event integration: production verification, 2026-09-24
Result: PASS against backend 94f0007cdb8b7eaf1a4850f5975b6b249e27b86c.
- Feature PR #739
- Successful backend production deployment
- Live verification: 15:37:45–15:39:11 UTC.
/healthreturned the expected baked commit and healthy database.
What was actually exercised
| Path | Live evidence |
|---|---|
| Portal | Signed in through Clerk with an isolated temporary account. Copied the configured brand's Website install ID. Created a Write token through the actual UI, copied its one-time plaintext, and used it below. |
| HTML | Executed the guide's actual snippets in Chromium, loading https://arenza.ai/sdk/v1.js. Real production /session and /events requests succeeded. Database readback showed one visit and one interaction for the SDK visitor, with no billing receipt. |
| JavaScript | Same checks using the guide's explicit create → init → track snippets. |
| Python | Ran the linked, unchanged arenza_events.py against production with a configured test event and the Portal-created Key. Received 202; the production worker completed processing. |
| Go | Compiled and ran the linked, unchanged arenza/sender.go against production. Received 202; the production worker completed processing. |
| Readback | Python, Go and legacy-HMAC receipts were processed once each, for the correct brand and visitor. Statement lines were excluded with zero fees. Worker execution was automatic; no local worker or manually triggered cron was substituted. |
| Revocation | Revoked the Write token through the real Portal UI. Its next event POST returned 401. |
Negative checks: missing/unknown Key 401; read-only Key 403; another tenant's brand 404; measurement-only install 422; changed-body retry 409; invalid browser session 401. An unchanged Python retry returned the original receipt with duplicate: true. Existing HMAC reporting still returned 202 and processed successfully.
Finding that changed the documentation
The original statement that every browser origin must be a registered brand domain was incorrect. Production testing returned 200 for another valid HTTPS origin while reporting_origins was unset. Setting that optional restriction on the isolated fixture caused the same unlisted origin to return 403.
The quickstart and HTTP reference now distinguish optional reporting restrictions from session authentication and cross-domain identity exchange. No customer configuration or runtime origin policy was changed to make this check pass.
Scope and cleanup
The Chromium test website was an isolated HTTPS-origin fixture served locally by Playwright. The SDK, Portal, Clerk, API, database and background worker were real deployed services, not mocked responses. This proves the documented integration paths, not installation or consent behavior on Wati's or another customer's actual website.
Temporary fixture brands, tenants, API credentials and the Clerk account were removed after verification. No billing contracts/meters were created; no customer records were used; no paid scans or bulk model calls were invoked. Ordinary request/audit logs may remain. This does not establish arbitrary named-event support, revenue attribution accuracy, or billability.