API Security Standards

Every integration built on the Poptin API touches contact data, campaign controls, and email sending on live accounts. This page defines the security expectations for calling the API and for handling the credentials that authenticate those calls. Follow them to keep your integration - and your contacts - safe.

Transport

Use HTTPS only to reach the Public API. All operations are served from:

https://api.popt.in/v1

Do not attempt plain HTTP, mixed-content proxies, or TLS downgrades. Requests that don't terminate over TLS will be rejected. Verify TLS certificates in your HTTP client; do not disable certificate validation to work around network issues.

Protecting API keys

API keys are the sole credential for the Public API. Treat them like passwords.

• Create keys in the app at My Account → API & Connections → API Keys. Keys start with pk_live_ and are shown only once at creation - copy immediately and store in a secrets manager.
• Scope matters. Every key is bound to the account or subaccount it was created in. It cannot cross accounts, and access follows that scope for every call.
• Use least privilege. Where practical, create a separate key per integration (CRM sync, warehouse export, internal tool). Blast radius stays small if one is exposed, and you can revoke without breaking others.
• Rotate on suspicion. If a key may have been exposed - leaked commit, shared screenshot, departing contractor - revoke it and issue a new one immediately.
• Revoke what you don't use. Prune old keys on a regular cadence. Unused keys are a standing risk.

Never place a key in any of these locations:

• Frontend JavaScript, mobile app binaries, or browser extensions.
• Public or shared Git repositories, including in commit history.
• Client-side analytics, tag managers, or third-party trackers.
• Screenshots, screen shares, or public support threads.

Keys belong on the server, in environment variables or a secrets manager.

Safe client practices

Assume logs and support tickets will be read by someone other than you.

• Redact Authorization headers in application logs, HTTP tracing, and error reporters. If you must reference a key for debugging, use the prefix only (e.g. pk_live_…) - never the full value.
• Strip keys from tickets and public channels. Do not paste full keys into GitHub issues, chat rooms, screenshots, or the docs feedback widget.
• Handle 401 / 403 cleanly. Fail closed, alert your team, and rotate the key rather than retrying with the same credential.
• Isolate test credentials. Use the practices in Testing the API when experimenting.

Reporting issues

If you discover a suspected vulnerability, key leak, or abuse of the Public API, contact Poptin support at [email protected]. Include the affected key prefix (never the full key), timestamps, and what you observed. See How to get support for other channels.

Related