Skip to main content
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

Last modified on June 17, 2026