Building a Terraform Provider for Paddle Billing: Why Real‑Sandbox Testing Matters

Description and use

A Terraform provider for Paddle Billing was built to manage catalog items and lifecycle actions, with real‑sandbox testing ensuring API schema correctness.

Problem

Existing tooling did not cover the full Paddle Billing catalog and lifecycle actions, forcing manual management via the dashboard.

Outcome

The provider enables declarative management of Paddle Billing resources, reduces manual dashboard work, and ensures correctness through real‑sandbox testing, catching bugs that mocks would miss.

Workflow

• 1. Identify missing Paddle Billing features in existing tooling.
• 2. Design provider schema for products, prices, discounts, notification settings, and lifecycle actions.
• 3. Implement provider with data sources for subscriptions, transactions, customers, and events.
• 4. Add an OpenAPI spec vendor copy and run forward‑only contract checks against Paddle’s real sandbox API for every test run.
• 5. Implement an ephemeral resource for webhook signing secrets to avoid storing sensitive data in state.
• 6. Enable resource identity and list resources to support terraform query for bulk discovery and import.
• 7. Publish provider on Terraform Registry and host source on GitHub.
• 8. Continuously test against real sandbox accounts to catch schema mismatches.

Evidence

Every resource and data source is verified end‑to‑end against Paddle's real sandbox API before each release, not just tested against mocks.

Source

Paddle publishes a proper machine‑readable OpenAPI spec for their whole API, auto‑generated from their own backend whenever it changes.

Source