> ## Documentation Index
> Fetch the complete documentation index at: https://docs.liquidramp.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Security

> API keys, signing, webhooks, validation, and customer data for partner integrations.

This page covers the controls you will encounter as an API consumer. Liquidramp does not claim PCI DSS, SOC 2, or ISO 27001 certifications here.

## Controls

| Control                | What it means for you                                                                         |
| ---------------------- | --------------------------------------------------------------------------------------------- |
| API key authentication | `pk_*` / `sk_*` with your partner reference                                                   |
| Request signing        | HMAC-SHA256 on `sk_*` writes — see [Authentication](/getting-started/authentication)          |
| Webhook signing        | HMAC-SHA256 on outbound deliveries — see [Webhook verification](/guides/webhook-verification) |
| IP whitelist           | Optional, configured in the portal                                                            |
| Input validation       | Invalid bodies return `422`                                                                   |
| KYB                    | Quote and order writes require an approved partner account                                    |
| End-user KYC           | Required for onramp and offramp. Prefer a KYC provider. Not required for swap                 |

**Your responsibilities:** complete KYC on end users for onramp and offramp (preferably via a KYC provider), store keys in a secrets manager, verify webhook signatures, use a unique `merchant_reference` on order creates, enable the IP whitelist in production, and never embed `sk_*` or `enc_*` in client-side code.

## End-user KYC

Liquidramp expects you to KYC your users — preferably through a KYC provider — so the platform stays compliant when fiat is involved. Partner KYB in the portal verifies your business; it does not replace customer KYC.

| Flow    | End-user KYC |
| ------- | ------------ |
| Onramp  | Required     |
| Offramp | Required     |
| Swap    | Not required |

## Access control

| Method              | Typical use                                  | Signing       |
| ------------------- | -------------------------------------------- | ------------- |
| Public key (`pk_*`) | Read requests (reference data, rate preview) | None          |
| Secret key (`sk_*`) | Backend only — reads and writes              | HMAC required |

* Quote and order writes require an approved KYB status. Unapproved accounts receive `403`.
* Optional IP whitelist: requests from other IPs return `E_IP_BLOCKED`.
* Orders are scoped to your partner account. Another partner's reference returns `404`.
* API keys do not expire until you rotate them in the portal. Creating a new key set revokes the previous set.

## Webhook handlers

Outbound webhooks use the same HMAC scheme as inbound API requests (`liquidramp-signature`, `liquidramp-timestamp`, signed with `enc_*`).

1. Read the raw body before JSON parsing
2. Reconstruct the canonical string with your partner reference
3. HMAC-SHA256 with `enc_*`
4. Timing-safe comparison against `liquidramp-signature`
5. Reject timestamps outside a ±5 minute window
6. HTTPS only in production; return `2xx` before heavy processing; handle duplicate deliveries

Delivery logs are available in the partner portal.

## Input validation

Invalid request bodies return HTTP `422` with `E_VALIDATION_ERROR`. Do not retry `422` without fixing the payload. Map messages to form fields and redact PII in production logs.

**Orders:** `customer.reference`, `customer.name`, and `customer.email` are required. Pass `quote_id` or `from`/`to` legs.

**Recipient shape:** offramp needs `institution_code`, `account_number`, and `account_name`. Onramp and swap need `address` (optional `memo`).

**Quotes:** exactly one of `from.amount` or `to.amount`. Both legs use `currency`. Crypto legs require `network`; fiat legs must omit it. Swap requires both legs crypto on the same network.

**Fulfilment:** Payment is auto-detected. `POST /v1/orders/:reference/fulfill` is optional (bank `reference` for fiat, or `tx_hash` for crypto) when confirmation is delayed.

## Customer data

Liquidramp processes customer data you submit on order creation. This is not a legal privacy policy.

| Field       | Required | Purpose                      |
| ----------- | -------- | ---------------------------- |
| `reference` | Yes      | Your user identifier         |
| `name`      | Yes      | Fulfilment                   |
| `email`     | Yes      | Notifications, support       |
| `phone`     | No       | Contact                      |
| `dob`       | No       | Age verification if required |
| `address`   | No       | Compliance if required       |

Order responses include `customer_reference`. `payin` and `payout` contain account numbers and wallet addresses needed for fulfilment. Webhook payloads include `customer_reference` only, not the full customer profile.

Collect only data required for the transaction, inform end users per your jurisdiction, and do not log full account numbers or private keys. Use HTTPS for API calls and webhook endpoints. Liquidramp does not process card PANs; fiat pay-in uses bank transfers.

## Related

* [Authentication](/getting-started/authentication)
* [Webhook verification](/guides/webhook-verification)
* [Going live](/getting-started/checklist)
* [Error handling](/guides/error-handling)