API Backends as Tor Hidden Services: Architecture and Implementation

Several application categories benefit from API backend hidden services. Privacy-focused applications: user-facing apps (mobile, desktop) that route all API calls through Tor to prevent the server from logging user IP addresses. Whistleblower apps: mobile or web apps for submitting sensitive information anonymously through .onion API endpoints. Private collaboration tools: small-group applications where all participants prefer network anonymity. Research data collection: mobile survey apps that route data submission through Tor to prevent IP linkage. The common thread is applications where the client-server connection metadata (IP logs) represents a privacy risk that the .onion architecture addresses.

API design for hidden service backends follows standard REST principles with additional performance considerations for Tor's latency. Minimize round trips: design responses to include all needed data in a single response (avoid API designs that require multiple sequential requests for a single user action). Use HTTP/2 (multiplexed requests over a single TCP connection reuse the Tor circuit without setup overhead). Implement aggressive response caching with appropriate cache-control headers. Use batch request patterns for operations that naturally involve multiple resources. GraphQL is well-suited for hidden service APIs because a single query can fetch all needed data, minimizing Tor circuit round trips.

Standard authentication patterns apply with Tor-specific considerations. JWT (JSON Web Token) authentication is ideal: tokens are self-contained and stateless, allowing any backend instance to verify them without shared session storage. TOTP second factor works well with Tor - TOTP authenticator apps do not require network access to generate codes. Password hashing (bcrypt/argon2) with appropriate work factors protects credentials if the database is compromised. Do not use SMS-based authentication (requires phone number). WebAuthn/FIDO2 hardware keys work but the device registration flow requires the user to have a consistent hidden service URL for origin binding.

Mobile apps connecting to .onion API backends require Tor integration at the app level. iOS and Android have no native Tor support. Options: OrbotLib (Android library integrating Orbot for SOCKS5 proxy), Onion Browser's WebView for iOS apps, or custom Tor integration using the Tor framework. For cross-platform React Native or Flutter apps, community packages provide Tor integration. The client app configures SOCKS5 proxy pointing to Tor, then makes HTTP requests to the .onion API URL through standard HTTP client libraries that support SOCKS5. Performance testing with Tor latency in the client development environment prevents surprises in production.

Horizontal scaling of API backends behind hidden services uses the OnionBalance approach (multiple backends, aggregated introduction points) or a load balancer accessible via hidden service. Container orchestration (Docker Compose, Kubernetes) manages multiple API service instances. Each instance connects to a shared database (PostgreSQL, MongoDB) accessible via internal Docker network. The Tor daemon runs as a sidecar container (separate container in the same network) exposing the .onion address. Database connections remain on the internal Docker network, invisible from outside. CI/CD deployment updates container images while maintaining the .onion address (the Tor container persists across deployments).