Paqueterías
Paquetexpress
Integración con Paquetexpress (PQTX) — paquetería nacional MX. Slug: paquetexpress. Modelo de datos custom (no usa la tabla shared orders).
Datos disponibles
- Guías con ~55 campos por guía: status, tracking, eventos.
- Tracking events: SWB (recibida), HCA (en hub), TRN (en tránsito), EAD (en agencia destino), ENT (entregada).
Cómo conectar
Desde Onboarding → Paquetexpress. Flujo de dos pasos:
- Genera tu webhook URL en SELLERP (256-bit secret per-org). Se la mandas a tu ejecutivo de PQTX por email (template incluido).
- Cuando PQTX te entrega usuario + token, los pegas en SELLERP y ya. Sync inicial desde 01/01/2026 corre automático.
Generación de guías WMS
Pre Envíos puede generar guías Paquetexpress en lote sin mover todavía las líneas a Envíos. La acción usa los defaults configurados en /settings/logistics, conserva el pre envío en staging y guarda un intento auditable por renglón en fulfillment_carrier_guides.
El payload sigue el layout operativo validado en Sheets: RFC destino default XAXX-010101-XXX, país MEXICO, código de bulto 3, contenido COLCHON, tipo de entrega 2, forma de pago PAID, acuse N, cobertura N, tipo de servicio ST e ID producto 56101508. Peso y dimensiones salen del producto canónico/equivalencias SKU; si faltan, la generación se bloquea antes de llamar a PQTX.
La respuesta se normaliza a rastreo, guía, importe, saldo disponible, ZPL y PDF cuando PQTX los devuelve. El endpoint productivo default es https://cc.paquetexpress.com.mx/RadRestFul/api/rad/v1/guia; PQTX_GENERATE_GUIDE_URL queda sólo como override para QA o contingencias.
Webhooks
Endpoint canónico: POST https://api.sellerp.com/webhooks/paquetexpress/[orgPublicId]?secret=PER_ORG. El host api.sellerp.com es la única superficie aceptada en producción; legacy hosts (sellerp.com, app.sellerp.com) responden 410 Gone.
Secret per-org (256 bits) almacenado encriptado en marketplace_accounts.webhook_secret. Validación timing-safe sin fallback global — cuentas legacy sin secret deben re-conectarse para generar uno nuevo.
Idempotencia: ON CONFLICT DO NOTHING sobre la dedup key (org_id, rastreo, evento_id, fechahora) en pqtx_shipment_events. El campo source="webhook" se asigna exclusivamente cuando el evento entró por este handler — tracking-history sync asigna source="tracking_history".
Auditoría: cada recepción válida (post secret + post Zod) deja una fila en pqtx_webhook_receipts con linked reflejando si el evento se pudo ligar a un shipment existente.
Eventos huérfanos (rastreo todavía no sincronizado) entran con pqtx_shipment_id=null y se reconcilian con la RPC reconcile_pqtx_orphan_events en cada tick del sync incremental.
Sync
3 Inngest functions: incremental 0 * * * * como guardia webhook-aware con safety cada 6h, tracking-history 0 */2 * * * para re-fetch de fechas con cambios, e initial sync desde 01/01/2026 al conectar. Webhooks son la vía rápida; el polling/getReport es respaldo para huecos.