Prerequisites
Before you begin, prepare:- a trusted server runtime and application authentication boundary;
- a disposable personal workspace Praxa key with only the tutorial’s required scopes;
- synthetic input plus a persisted application request ID for replay tests;
- a fake upstream for unit tests and a non-production environment for canaries;
- an acceptance assertion that proves the chosen framework preserves the same server-owned credential, authority, and replay contract.
Shared boundary requirements
Every framework implementation should:- Authenticate the application user before accepting work.
- Derive the tenant or workspace from the session, not the request body.
- Validate and bound user input before forwarding it.
- Create one stable idempotency key per logical mutation.
- Keep Praxa keys, OAuth tokens, provider clients, and webhook secrets server-only.
- Return only customer-safe Praxa projections to the browser.
- Rate limit by the authenticated principal and application use case.
Next.js App Router
app/api/tasks/route.ts
NEXT_PUBLIC_. That would make it eligible
for the client bundle.
Express
Cloudflare Workers or Hono
wrangler secret put PRAXA_API_KEY, not in
wrangler.jsonc or source control.
FastAPI
React, Vue, and Svelte clients
Frontend frameworks use the same application backend boundary:api.praxa.io with a server API key or receive provider credentials.
Verify the framework boundary
- Search the production client bundle for
praxa_sk_, webhook secrets, and OAuth tokens; require zero matches. - Call the route without an application session and require
401before any Praxa request. - Send an over-limit input and require
400before any Praxa request. - Submit valid input and require a customer-safe run projection.
- Retry with the same application request ID and require the same logical run.
- Attempt to supply a tenant or workspace ID in the browser body and require it to be ignored or rejected.
- Revoke the backend Praxa credential and require the route to return a safe, non-secret error.
Troubleshooting
Best practices
- Authenticate, rate-limit, and validate a bounded body before calling Praxa.
- Derive tenant and subject from the application session, never client input.
- Reuse clients and connection pools; set connect, request, and total deadlines.
- Persist request identity before the first mutation and reconcile ambiguous outcomes.
- Scan production client assets and telemetry for credential-shaped values.
Optimize for production
- Reuse one configured HTTP or SDK client per process and bound concurrent upstream work.
- Prefer durable admission plus asynchronous readback over holding application requests open.
- Cache only non-sensitive, tenant-scoped reads within their documented freshness window.
- Measure p50/p95 latency, admission-to-terminal time, retries, conflicts, and connection reuse before tuning.
Cleanup and next steps
- Revoke the disposable Praxa key and require a later request to fail.
- Remove synthetic application records and any temporary environment files.
- Cancel or archive unresolved test runs according to the application policy.
- Retain only redacted request, run, and verification identifiers needed for the test record.