This document summarises how Zillapi builds and changes its software, and the controls we apply to protect the production service and our customers’ data. It is intended to give customers and their security teams a clear, accurate picture of our software-development and change-management practices.

Source control and change tracking

All Zillapi application code is maintained in a private Git repository (GitHub) with a complete, auditable history. Every change is made through a pull request with a written description of what is changing and why, so the provenance and intent of everything that reaches production is recorded and reviewable. Changes are reviewed before they are merged into the main branch.

Change management and deployment

  • Deployment is automated from the main branch to our managed hosting platforms (Cloudflare and Supabase). Customers do not install or patch any software; every customer always runs the current, centrally-maintained version.
  • Significant or sensitive changes are introduced behind feature flags and validated in a shadow or limited-rollout mode before being fully enabled, so new behaviour can be observed against production traffic without affecting customers, and can be disabled quickly if needed.
  • Changes to sensitive areas — billing, credit accounting, and webhooks — are accompanied by automated checks and validation controls, and a daily automated reconciliation and compliance sweep runs against production to confirm that financial records remain consistent.

Environment separation

Local development is separated from the production environment. Production credentials, secrets, and data are isolated from development and are not used outside production. Access to the production environment and its secrets is restricted to authorised team members, and secrets are stored as platform-managed environment secrets — never committed to source control.

Secure development practices

Zillapi applies established secure-development practices, including:

  • A statically-typed (TypeScript) codebase, which eliminates common classes of error.
  • Input validation and least-privilege, scoped access to data and third-party services.
  • Verification of inbound webhook signatures, and constant-time comparison for internal authentication secrets.
  • Pinned dependency versions (lockfiles) for reproducible builds, with dependencies monitored and updated as security fixes become available.
  • Secrets and API keys held as managed environment secrets and kept out of the source tree.

Secure-design considerations are applied to the highest-risk parts of the system — authentication, API-key handling, billing and payment flows, and data access — with controls designed around how each could be misused.

Security updates

Because Zillapi is a centrally-hosted service, security updates are applied by us and take effect for all customers automatically, with no action required on the customer’s part. Where a change materially affects customers, we notify them directly.

Vulnerability handling

Security issues are tracked and remediated through our internal process. Our Vulnerability Disclosure Policy describes how to report a vulnerability and how we investigate, remediate, and — where customers are affected — disclose it directly to them.

Questions

We are happy to discuss our development and security practices in more detail with customers and their security teams. Contact us at hello@zillapi.com.