Problem and solution
An API is easier to reason about when its requests, responses, and failure states are visible. The console creates a direct inspection surface for the metrics function rather than hiding it behind the site experience.
ChallengeMake a small serverless endpoint observable without requiring a separate API client.
SolutionExpose GET health checks, POST event tests, raw responses, and representative charts in one console.
ResultA visible integration surface for validating contracts, CORS behavior, and failure handling.
Architecture
Browser
Request controls
Endpoint
Appwrite function
Response
Structured metric data
View
Representative visualization
API contract
RuntimeAppwrite Function on Node.js 20/22
MethodsGET health response, POST event receipt, and OPTIONS preflight
PayloadJSON event name, numeric value, and optional contextual fields
ResponsesStructured JSON with explicit 200, 204, 405, and 500 behavior
CORSRestricted to https://www.adcox.ai
Request exampleA minimal event sent from the console.
POST /metrics\nContent-Type: application/json\n\n{\n "event": "pageview",\n "value": 1\n}Engineering decisions
- Keep the testing surface separate from the primary site experience.
- Expose both machine-readable behavior and human-readable interpretation.
- Use the same shared shell so the utility remains part of the Adcox.AI system.
What this project demonstrates
- Designing and documenting a small REST-style serverless contract.
- Making success, failure, and preflight behavior visible to an operator.
- Separating representative visualization data from live endpoint behavior.
- Using CORS boundaries and explicit status handling rather than permissive defaults.