High-level technical architecture of BillerAPI
BillerAPI gives fintech apps a single, secure API to link billers and retrieve bills. Payment-method tooling is available, but bill-payment execution is not: initiation returns 501 PAYMENT_EXECUTION_NOT_AVAILABLE. This post outlines how the platform is built at a high level—domains, API gateway, microservices, authentication, data, and infrastructure—without diving into internal implementation details.
Domains and entry
In production, BillerAPI is exposed under a small set of domains. The main website and signup flow live at the primary marketing domain; the API used by developers and by our own frontends is on a dedicated API subdomain. Internal operations and workflow tooling use separate subdomains so we can apply different security and access policies. All public traffic is terminated with HTTPS and TLS at a reverse proxy, which routes by host and path to the appropriate service. This gives us a single place to handle SSL, routing, and consistent security headers.
Single API gateway
Developers and applications talk to one entry point: a unified API gateway. It exposes path-based routes for identity and access management (IAM), account linking, billers, bills, emails, and metering. The gateway also hosts internal-only paths for operations tooling. Health and API documentation endpoints are available so integrators can check status and explore the API. Keeping a single gateway simplifies integration, versioning, and consistent authentication and rate-limiting across all capabilities.
Microservices and gRPC
Behind the gateway, the platform is split into focused microservices. The gateway speaks to these backends over gRPC for performance and strong contracts. Services cover client identity and auth, bill lifecycle, email processing and classification, metering, and biller configuration. Each service owns its domain logic and data access patterns. This separation lets us scale and deploy pieces independently while keeping a single, coherent API surface for clients.
Authentication
The API supports two main audiences. External developers use API credentials (e.g. client IDs and secrets) to call the public routes; the gateway validates these and forwards requests to the right service. Internal operators use a separate authentication system (e.g. identity provider–backed sessions) to access ops-only endpoints. Public API documentation is available at the gateway so integrators can discover and test endpoints with the same auth model they use in production.
Data and events
Persistence is built around a primary database with indexes tuned for the main access patterns. Documents and binary assets are stored in object storage with appropriate retention and access controls. Application events are published to a central event bus so different services can react to things like new signups, link completions, or bill updates. Asynchronous job processing uses queues so heavy or slow work doesn't block the API. Longer-running workflows (e.g. multi-step onboarding or email classification) are orchestrated by a workflow engine that handles retries, timeouts, and visibility for ops.
Infrastructure as code
All of this runs on cloud infrastructure defined and updated as code. Stacks cover core data stores, compute, DNS, and monitoring so environments are reproducible and auditable. Production compute runs on virtual servers with containers for each service; the reverse proxy and TLS termination sit in front. DNS for the public domains is managed in the same codebase so new environments or domains are consistent. Emphasis is on consistent naming, tagging, least-privilege access, and security-focused defaults so the platform stays maintainable and safe as it grows.