Skip to main content
The PCI Proxy only sends card data to hosts you have explicitly registered. This is a deliberate safety control: even if your API credentials were stolen, an attacker could not forward your stored cards to a server you never approved. There is no “any host” mode. Managing your allowlist is self-serve — a hostname you add is usable within minutes, no support ticket required.
A destination not on your allowlist is rejectedA proxy request to an unregistered host returns 403 DESTINATION_NOT_ALLOWED. Register the host first with the endpoints below.

​
How matching works

The proxy only forwards to hosts that are registered and enabled on your allowlist. Matching is exact on the hostname:
  • Case-insensitive: API.Stripe.com and api.stripe.com are the same host.
  • No wildcards: api.example.com does not authorize sandbox.example.com.
  • Subdomains are registered separately.
A request to a host that is not registered, or is registered but DISABLED, is rejected with 403 DESTINATION_NOT_ALLOWED before any card data is read.

​
Register a destination

Returns 201 with the created entry, which starts in the ENABLED state. A hostname that is already registered returns 409 DESTINATION_EXISTS; a value that is not a bare public hostname (a URL, a host with a port or path, an IP address, or a wildcard) returns 422 INVALID_HOSTNAME; an account_id that is not a valid account for your organization returns 400 INVALID_ACCOUNT_ID. account_id is optional. Left null (the default), the destination is allowed for every account in your organization. Set it to a specific account id to scope the destination to that account only — the host is then usable solely on proxy requests made under that account. The destination object returns id, hostname, purpose, account_id, status (ENABLED / DISABLED), created_at, and updated_at. When you call via the API the actor is your API key, so the object does not carry a user email.

​
List your destinations

Returns {"destinations": [ ... ]} — only the destinations registered for your account.

​
Remove a destination

Returns 204. Removing a destination takes effect immediately — the next proxy request to that host is rejected.

​
Enable or disable a destination

Instead of removing a host, you can disable it — the record (and its audit history) is kept, but the forward path stops using it. Re-enable it to turn it back on. This is useful for temporarily suspending a destination without losing its configuration.
Each returns 200 with the updated destination object (its status set to DISABLED or ENABLED). Only ENABLED destinations are used by the forward path; a request to a DISABLED host returns 403 DESTINATION_NOT_ALLOWED. A destination moves through three states:

​
Audit trail

Every allowlist change — add, remove, enable, and disable — is written to an append-only audit log recording who made the change, when, and which hostname. The audit record persists even after a destination is removed, so a deletion is never invisible: you can always see who removed a host and when. There is no way to alter or erase these audit records through the API.
Treat new-destination and deletion alerts seriouslyAdding or removing a destination is a sensitive action: it changes where your cards can be sent. Yuno recommends restricting who can manage the allowlist, enabling notifications on allowlist changes, and reviewing any unexpected additions or deletions — they are the tripwire for a compromised dashboard account.