Corporate Plan · v1 StableREST HTTPS · JSON120 req/h · 500 records/batch

Connect your system once and stop uploading files.

Your customer dossiers and transactions arrive automatically in PLDUnity, ready for UMA thresholds, screening lists, and SAT XML reports. Built for high-volume or continuous operations (online casinos & betting, virtual assets, cards & prepay, financial entities) and their IT teams.

Request Corporate API Access Try Interactive Simulator View Technical Specs

REQUESTGET /ping

// Cargando payload ficticio...

AuthorizationBearer pldbdu_test_mock_ficticio_0000...

Content-Typeapplication/json; charset=utf-8

User-AgentPLDUnity-MockSimulator/1.0

Acceptapplication/json

# Generando comando cURL ficticio...

RESPONSE200 OK

34 msMock OK

// Presiona "Ejecutar Petición" para simular...

Conexión Verificada (Simulación)

Llave de API ficticia identificada. Permisos validados contra la huella SHA-256 de prueba.

Core Architecture

Engineered for Continuous AML Compliance

The PLDUnity API connects your user manager, back-office, or cashier directly with the AML compliance platform to register clients and ingest operations automatically.

Zero Manual Files or Captures

Customers and transactions arrive straight from your system via HTTPS REST. Each user becomes a dossier automatically without uploading CSVs.

Automated Ingestion

Always-Current Dossiers

Every onboarding or profile change in your manager updates the dossier in PLDUnity, assigning initial risk grade and queuing for list screening.

Dynamic Sync

Same Rules as the Platform

Everything entering via API undergoes the exact same validation, annual UMA thresholds, monthly and 6-month accumulation per client, and XML notice preparation.

Art. 17 LFPIORPI

Idempotent & Safe to Retry

Sending the exact same batch twice duplicates nothing. Your integration workers can safely retry after network interruptions without corrupting balances.

Zero Duplicates

Row-by-Row Feedback

Every rejected client or operation returns its specific row index and human-readable reason, alongside the generated dossier clave for accepted records.

Granular Diagnostics

Signed Webhooks

Outbound HTTP POST notifications to your system signed with HMAC-SHA256 when an XML report is generated or an identity verification changes status.

HMAC-SHA256

Simulate a flow in the 3D cluster:

Core PLD tower and intake gates (/clientes and /operaciones)Idempotent deduplication gate and batch sled (500 records)Radial gauge of monthly/semi-annual accumulation in UMA of the year

Technical Specification

Protocol, Scopes & Payload Schemas

Standard HTTPS JSON endpoints protected by 32-byte random keys hashed with SHA-256 and audited on every call.

URL Base y Formato

https://app.pldunity.com/api/v1

REST sobre HTTPS (TLS 1.3), JSON de entrada y salida en todos los endpoints.

Autenticación y Seguridad de Llaves

Authorization: Bearer pldbdu_...

También se acepta X-API-Key. Se generan con 32 bytes aleatorios, se guardan solo como hash SHA-256, son revocables y registran su último uso.

Permisos por Llave (Scopes)

clientes (enviar y consultar expedientes)operaciones (enviar operaciones)

Cada alta por API queda registrada automáticamente en la bitácora de auditoría de la plataforma.

Límite y Capacidad por Petición

120 peticiones / hora · Hasta 500 registros / lote

120 peticiones por hora por llave; hasta 500 clientes u operaciones por petición.

Inspect the key validator:

Bearer token reader and 32-division rotor (32 bytes)6 pins compare the SHA-256 fingerprint with the stored hash (the platform never stores the key in clear text)Independent scope gates (clientes and operaciones), 120 requests/hour gauge and audit log

Tabla de Endpoints (API v1)

Base: https://app.pldunity.com/api/v1

Método	Ruta	Permiso (Scope)	Para qué
GET	`/ping`	Cualquiera	Probar la llave; devuelve la empresa y el prefijo de la llave.
POST	`/clientes`	clientes	Alta y actualización de hasta 500 expedientes por lote.
GET	`/clientes`	clientes	Listar expedientes; filtros `limite` (1–200), `rfc`, `idExterno`, `desde` (fecha ISO).
GET	`/clientes/{clave}`	clientes	Un expediente por su clave (o `/clientes/_?idExterno=...`).
POST	`/operaciones`	operaciones	Hasta 500 operaciones por lote, con `periodo` (año y mes) y tipo de movimiento opcional (depósitos o retiros).

POST /clientes

Clientes: Campos y Reglas de Expediente

Obligatorios:idExterno (el ID en el sistema del cliente) y rfc (12 o 13 caracteres).
Regla para RFC genérico:Para XEXX010101000 (extranjero) y XAXX010101000 (público en general) también son obligatorios nombreCliente y apellidoPaterno; así cada persona queda en su propio expediente individualizado.
Opcionales:apellidoMaterno, curp, fechaNacimiento (AAAA-MM-DD), tipoPersona (FISICA o MORAL), actuaNombrePropio, domicilio y contacto, actividad económica, nacionalidad, país y beneficiario controlador.
Cálculo de clave:La plataforma calcula la clave del expediente a partir del RFC (o del RFC genérico más el nombre) y la devuelve en clave para que el sistema del cliente la guarde.

Ejemplo de respuesta de POST /clientes (Ficticio):

{
  "ok": true,
  "recibidos": 1,
  "creados": 1,
  "actualizados": 0,
  "rechazados": 0,
  "resultados": [
    {
      "index": 0,
      "idExterno": "ID-FICTICIO-001",
      "clave": "MOCK010101XYZ",
      "estado": "creado"
    }
  ]
}

POST /operaciones

Operaciones: Campos y Acumulación UMA

Obligatorios por operación:fechaOperacion (AAAA-MM-DD), monto (> 0) y rfcCliente, o bien nombreCliente + apellidoPaterno.
Parámetros de lote:Incluye periodo (año y mes) y tipo de movimiento opcional (depósitos o retiros), con hasta 500 operaciones por petición.
Opcionales por actividad:Tipo de operación, moneda, instrumento monetario, datos del cliente y su domicilio, beneficiario controlador, y campos de juego (tipo de juego, cuenta, folio, premio).
Respuesta detallada:Informa operaciones procesadas, rechazadas, duplicadas omitidas, con advertencias, resumen de riesgo en UMA y el lote creado.

Ejemplo de respuesta de POST /operaciones (Ficticio):

{
  "ok": true,
  "loteId": "LOTE-MOCK-2026-001",
  "procesadas": 1,
  "rechazadas": 0,
  "duplicadasOmitidas": 0,
  "conAdvertencias": 0,
  "resumenRiesgo": {
    "cliente": "MOCK010101XYZ",
    "superaUmbralAvisoUMA": true
  }
}

Integration Flow & Webhooks

5-Step Connection & Signed Webhooks

Generate your key, send client and operation batches, and receive signed HMAC-SHA256 webhook alerts with automatic retries.

Genera tu llave de API

El administrador genera una llave en la plataforma (Cargar operaciones → Conectar mi sistema, o Configuración → API Keys) y elige sus permisos (clientes, operaciones).

Huella única SHA-256

La llave se muestra una sola vez; la plataforma guarda solo su huella (hash SHA-256). Si se pierde, se revoca y se genera otra al instante.

Envío en lotes

El sistema del cliente envía clientes y operaciones a la API en lotes de hasta 500 registros, guardando la clave devuelta para cada expediente.

Webhooks firmados (Opcional)

Configura webhooks con firma HMAC-SHA256 para recibir avisos cuando se genera un XML o cambia una verificación de identidad.

Documentación en plataforma

La documentación interactiva completa y la bitácora de auditoría están dentro de la plataforma, en la sección de documentación de la API.

Especificación Técnica de Webhooks Firmados

POST a la URL que configure el cliente, firmado con HMAC-SHA256 usando el secreto del webhook.

X-PLDBDU-Event: Nombre del evento disparado.
X-PLDBDU-Signature: Firma criptográfica HMAC-SHA256 del cuerpo.
X-PLDBDU-Delivery: ID único de entrega para descartar duplicados.

Política de reintentos automáticos: Si la entrega falla (sin respuesta, 408, 429 o 5xx), PLDUnity reintenta a 1 min, 5 min, 30 min, 2 h y 12 h con el mismo cuerpo y el mismo ID de entrega. Tiempo de espera por intento: 10 segundos.

Eventos Activos

xml_generatedCuando se genera un archivo XML de aviso en la plataforma.

threshold_reachedCuando un cliente alcanza el umbral de identificación o de aviso en UMA.

payment_failedNotificación administrativa de pago fallido en la cuenta.

operation_flaggedCuando una operación es marcada por reglas de monitoreo o alerta.

verification_submittedVerificación de identidad enviada por el cliente.

verification_completedVerificación de identidad terminada (aprobada o rechazada).

verification_resubmission_requestedVerificación con solicitud de corrección o reenvío de documento.

verification_expiredEl enlace o sesión de verificación venció sin completarse.

Try the 3D dispatcher:

HMAC-SHA256 sealing chamber, 10s timer and dispatch antennaStepped bank of 5 retry stages (1 min, 5 min, 30 min, 2 h, 12 h)Same X-PLDBDU-Delivery on every retry to avoid duplicates

Error Diagnostics

Structured JSON Errors with Row Detail

Every rejected request returns ok: false with a clear message and row-by-row details on batch payloads.

400 Bad Request

Datos inválidos o campos obligatorios faltantes; en envíos por lotes, devuelve el detalle renglón por renglón con su index.

401 Unauthorized

Llave de API ausente en el encabezado o previamente revocada por el administrador.

403 Forbidden

La llave es válida pero no tiene el permiso (scope clientes u operaciones) requerido para la ruta.

404 / 405

404 Not Found (expediente o ruta inexistente) o 405 Method Not Allowed (verbo HTTP incorrecto).

409 Conflict

Conflicto de integridad: existe más de un expediente registrado con el mismo idExterno.

429 Too Many Requests

Se alcanzó el límite de 120 peticiones por hora para la llave. Aplicar reintento con espera creciente.

503 Service Unavailable

Servicio de autenticación temporalmente no disponible; seguro de reintentar con espera creciente.

Buenas Prácticas para el Integrador

Lotes de 200 a 500 registros:Agrupa tus envíos en lotes de 200 a 500 clientes u operaciones y aplica reintento con espera creciente (backoff exponencial) ante códigos 429 y 503.
Guardar la clave de cada expediente:Almacena en tu base de datos la clave devuelta por POST /clientes para futuras consultas directas.
Reconciliación nocturna con GET /clientes?desde=...:Sincroniza deltas en un proceso nocturno usando el parámetro ISO desde en lugar de reenviar todo el padrón.
Sin borrado por API (Conservación regulatoria):No existe endpoint para borrar clientes; los expedientes se conservan íntegros por obligación regulatoria de la LFPIORPI.

Alcance Operativo y Regulatorio

Generación y presentación del XML al SAT:El archivo XML oficial se genera dentro de la plataforma PLDUnity y se presenta en el portal del SAT (no se presenta al SAT por API).

Screening en barrido diario:Al dar de alta un cliente por API, su expediente recibe su grado de riesgo inicial y entra en cola para ser cotejado en el barrido diario contra listas.

Conexión estándar HTTPS REST:Integración directa mediante JSON y llaves de API Bearer desde cualquier lenguaje de programación, sin requerir SDKs propietarios ni flujos OAuth complejos.

Included in the Corporate Plan

Connect Your System Once and Automate Your AML Compliance

The integration API (https://app.pldunity.com/api/v1) and signed HMAC webhooks are included in the PLDUnity Corporate plan (from $19,900 MXN/month + VAT). Schedule a technical session with the BDUnity team.

Contact BDUnity for Corporate Plan Compare Plans & Pricing