Backend API contract, configuration requirements, and deployment-verification status
The code defines nine API paths for SIWE, sessions, gating, loyalty, attribution, and anti-abuse checks. This page separates that implementation from target-environment configuration and independently verified production behavior.
| Method | Path | Purpose | Status |
|---|---|---|---|
GET | /api/v1/health | Reports operational web3 capability status. | Implemented · verify deployment |
GET | /api/v1/config | Publishes public feature state and policy routes. | Implemented · verify deployment |
GET | /api/v1/nonce | Issues replay-safe SIWE nonces. | Implemented · verify deployment |
POST | /api/v1/verify | Verifies SIWE signatures and prepares wallet auth. | Implemented · verify deployment |
GET | /api/v1/session | Reads authenticated wallet session state. | Implemented · verify deployment |
POST | /api/v1/gate-check | Checks local or ERC-721 token-gating rules. | Implemented · configuration required |
GET | /api/v1/loyalty-status | Reads off-chain or contract-backed loyalty status. | Implemented · configuration required |
POST | /api/v1/attribution-record | Persists explicit first-party wallet attribution records. | Implemented · verify persistence |
POST | /api/v1/bot-check | Runs heuristic anti-bot scoring. | Implemented · verify deployment |
Implementation and deployment status
The code implements these paths, but production behavior depends on secrets, RPC access, contract addresses, and the target environment. Treat a feature as live only after an independent end-to-end check confirms that deployment, and keep a conventional non-wallet fallback because no traveler path may be Web3-only.
Commissioning evidence required for live status
- Record the target environment, deployed revision, configuration fingerprint, and test time.
- Exercise the customer-visible success, rejection, unavailable, recovery, and privacy paths end to end.
- Verify persistence, session, provider, and contract behavior through an independent test operator.
- Publish the evidence reference and freshness date before changing beta to live.
- Revert the status when material configuration changes invalidate the evidence.
Use the stable readiness registry, capability changelog, architecture specs, and policy contracts together. None is commissioning evidence by itself.
Common questions
Are the backend endpoints still only scaffold responses?
No. Several endpoints now perform real work, including SIWE/session support, token-gating logic, first-party attribution persistence, and heuristic bot scoring.
Which features still depend on environment configuration?
Contract-backed token gating and on-chain loyalty require deployed contract addresses and a configured RPC endpoint.
Evidence, freshness, and corrections
- Written and edited by
- Rachel Julian, founder and editor
- Last reviewed
- 2026-08-13
- Readiness rule
- Scaffold means designed, not implemented. Beta means implemented with production verification pending. Live means independently verified end to end. Source code, ABI files, endpoints, or configuration never prove production availability.
- Correction path
- Report a correction or compare the capability changelog.
Source hierarchy
- Primary standards: Protocol specifications and standards bodies define what an implementation must do.
- Security guidance: Threat-model and identity guidance define controls, failure handling, and recovery expectations.
- Deployment evidence: Independent end-to-end checks establish whether a configured production capability is live.
- Editorial judgment: I apply those sources to revenue-travel decisions and state where the evidence stops.