To maintain robust data routing and prevent runtime failures, Hoox enforces a strict payload contract across all internal and public service boundaries. All incoming requests are validated by active JSON Schema or Zod middleware before entering V8 execution loops.
This document details the exact JSON schemas, TypeScript interfaces, and validation rules for all primary request payloads.
🛡️ 1. Standard Request Envelope
Every service-to-service invocation (via Service Bindings) wraps its business parameters inside a standardized Request Envelope containing distributed tracing indices:
📈 2. Trade Execution Payloads (trade-worker)
The execution engine processes two primary types of order payloads:
A. Centralized Exchange Order Payload (/webhook & /process)
B. On-Chain DeFi Swap Payload (/dex)
🗄️ 3. Database SQL Query Payloads (d1-worker)
The SQLite database proxy accepts parameterized SQL statements to protect against SQL injections:
A. Execute Single SQL Statement
💬 4. Telegram Notification Payloads (telegram-worker)
Used to push structured alerts and charts to your mobile device:
Adding new fields to a payload schema? Remember to update the corresponding
type interfaces in @jango-blockchained/hoox-shared/types to ensure complete
type safety across all workers!
🔗 Next Steps