A Paddle key that genuinely cannot write
Paddle grants read and write separately, which makes this the one key here you can verify for yourself.
The four permissions, and what each one powers
In Paddle, go to Developer tools, then Authentication, and create an API key. Permissions are listed per entity, with read and write as separate grants. Four reads, nothing else.
transaction.read powers every revenue figure on the site — the headline total, the trend, refunds, revenue by product and by country, and the orders table itself. subscription.read powers monthly recurring revenue, the active and cancelling counts, the subscription mix and the subscriptions table. customer.read powers the buyer name and email on an order at a provider that does not put them on the order itself, and the mirrored customer records. product.read powers the products table — what you sell, with what it has earned beside it wherever the provider attaches a product to an order.
- transaction.read
- Every revenue figure and the orders table
- subscription.read
- Recurring revenue and the subscriptions table
- customer.read
- Buyer details a transaction does not carry
- product.read
- The products table
Check it yourself, on Paddle's own screen
This is the part no other provider here allows. Open the key in Paddle after creating it and read its permission list back: if the only entries are those four `.read` grants, the key cannot write, and you have established that from Paddle rather than from anything on this page.
Do that once and you never have to take our word for the central claim of this product for your Paddle account. It is also why the connect form can name the exact four strings rather than describing them — there is a checkable answer, so it gives you one.
Billing, not Classic — and how to tell which you have
Paddle has two generations of API and only the current one is supported here. If your Paddle dashboard offers Developer tools and Authentication with per-entity permissions, you are on Paddle Billing and this guide applies.
If instead you have a vendor ID and an auth code, that is Paddle Classic, which is a different API with a different permission model and no equivalent read-only grant. There is no way to connect a Classic account, and a Classic credential pasted in will be refused rather than half-working.
Replacing or revoking the key
There is no replace-the-key screen today, and this page is not going to imply one. Changing the credential means disconnecting the account here and connecting it again with the new one. Disconnecting deletes the mirrored copy of that account's rows, which is why it is confirmed in place with a sentence naming exactly what goes; the first sync after reconnecting rebuilds it from Paddle. Nothing is lost permanently, but it is a rebuild rather than a swap, so do it when you can wait for a sync.
Revoking the key at Paddle without reconnecting is the gentler case: the account and its last-synced figures stay exactly where they are, and the failure is recorded against it rather than silently swallowed.
While it is stored, the key is encrypted with AES-256-GCM under a per-value random initialisation vector before it reaches the database, and decrypted only inside the sync. Nothing derived from it beyond a short hint is ever sent to the browser.
