Public keys and origins
Understand why a browser key can be public and how Public App policy limits where it is used.
A pk_ez_... key is safe to ship in frontend code: it identifies a Public App
rather than granting account access. What limits a copied key is that app's
policy — its allowed application origins and allowed source hosts.
zip.download({
strategy: 'cloud',
publicKey: 'pk_ez_...',
files: urls,
});Is the public key a secret?
No. A pk_ez_... key is designed to ship in frontend code and remain visible
in browser developer tools. It identifies a Public App; it does not replace
authorization on your own backend.
Do not expose a secret API key
Secret Cloud API keys belong on a trusted server. They are not accepted as a
safer substitute for publicKey in browser code.
What limits a copied key?
The Public App policy checks two independent boundaries:
| Policy | Contains | Protects |
|---|---|---|
| Allowed application origins | Exact frontend origins such as https://app.example.com | Which browser applications may create sessions |
| Allowed source hosts | Asset hosts such as cdn.example.com | Which remote files Eazip Cloud may fetch |
A copied key used from another origin, or with a source outside the host policy, is rejected.
How should environments be separated?
Add every intended origin to one Public App when the environments share the same source policy. Create separate Public Apps when staging and production need different hosts, limits, ownership, or key rotation.
Policy changes belong in the dashboard, not in extra SDK options — see Get a public key for the steps.