Notas de versión — Documentación Panadata API

14 de octubre de 2026

Sin saldo suficiente, el API dice cuánto falta y qué hacer

Nuevo: el 402 de una llave con saldo que no alcanza trae el código insufficient_credits, lo que cuesta la llamada (price), el saldo (balance), lo que falta (shortfall) y el enlace de recarga (upgrade_url). Antes traía solo error, que conserva su texto de siempre. Si el saldo todavía cubre una ficha DAT-FREE, el cuerpo lo dice en hint: la ficha DAT-FREE sigue respondiendo.
Nuevo: el 429 del tope de gasto mensual que fija el dueño de la cuenta trae el código spending_limit_exceeded, el tope (limit), lo gastado en el mes (consumed), lo que cuesta la llamada (price) y settings_url, la sección de Facturación donde se sube o se quita. error, resets_at y la cabecera Retry-After siguen igual.
El MCP lee los dos y le dice al agente el saldo, el precio y el paso siguiente. Las tres copias publicadas del spec v5 quedan alineadas con el gateway (6907c08); la copia en inglés es verbatim.

13 de octubre de 2026

La búsqueda en planillas ahora tiene eje temporal

Nuevo: POST /v5/search/planillas acepta fecha_inicio_min y fecha_inicio_max, la fecha de inicio en el cargo. Con pep_min cuenta, por ejemplo, los cargos (filas de planilla) con pep_score alto que empezaron en un período; para contar personas, usar la faceta personas. El pep_score es una señal derivada del cargo: no confirma que alguien sea PEP.
Nuevo: faceta personas, personas distintas por cédula válida: las cédulas placeholder (como 8-88-88) o truncadas no cuentan. Una persona tiene varias filas de planilla, así que total_approx cuenta filas y no gente. Es prácticamente exacta por debajo de unas 40.000 personas y aproximada por encima, por ejemplo en una búsqueda sin filtros sobre toda la planilla.
Nuevo: facetas monthly_inicio (filas por mes de inicio), sin_fecha_inicio (filas sin fecha de inicio, que ningún rango de fechas alcanza) y sin_cedula (filas sin cédula válida: vacía, placeholder o truncada; es el complemento exacto de las filas que cuenta personas).
Corrección (el mismo día, 729ecf9): en una búsqueda con fecha_inicio_min o fecha_inicio_max, la faceta sin_fecha_inicio salía en 0, porque el mismo rango la filtraba. Ahora se cuenta ignorando el rango de fechas y con todos los demás filtros: en la misma consulta trae las filas sin fecha que el período deja fuera.
Las tres copias publicadas del spec v5 quedan alineadas con el gateway (f39f67e); la copia en inglés es verbatim.

8 de octubre de 2026

Todo contador de presencia en 0 se verifica en la llamada

Corrección: cualquier contador de presencia.counters que diga 0 se verifica en la llamada contra las filas que sirve su sección, no solo css_moroso. En una muestra de 30.000 entidades había contadores en 0 con datos reales en 18 de las 19 superficies (avisos, expedientes, bienes muebles, fincas, importaciones…), y el código de esa superficie no aparecía en available_codes. POST /v5/resolve/batch con with_presence aplica la misma verificación.
Cambio de forma: un contador individual puede venir en null si su verificación pasa de 100.000 filas: hay datos, pero el número exacto no se contó. Su código sigue en available_codes.
El diccionario de claves se regeneró desde el gateway (master 5184361). El spec v5 no cambió.

8 de octubre de 2026

El mapa de presencia ya no hace pasar «no sabemos» por «no hay nada»

Corrección: cuando una entidad no tiene el mapa de presencia calculado, presencia.counters y presencia.available_codes de DAT-CORE vienen en null. Antes venían con todos los contadores en 0 y la lista vacía, que se leía como «no hay nada más que comprar». En DAT-FREE, codigos_con_datos también es null en ese caso. Una lista vacía [] sigue significando que el mapa no muestra nada más.
Corrección: el contador css_moroso se verifica en la llamada cuando dice 0. Miles de entidades con menciones en los listados de morosos de la CSS lo tenían en 0, y DAT-RISK no aparecía en available_codes aunque había datos.
Nuevo: POST /v5/resolve/batch con with_presence trae summary.presence_unknown: cuántas filas resueltas no tienen mapa de presencia y por eso no suman a ningún código.
Nuevo: GET /v5/entities/{{id}}/real-estate devuelve por defecto una fila por inmueble (view=compact), con limit/offset y items_meta para paginar. El historial completo de gravámenes y compraventas está en view=full.
Las tres copias publicadas del spec v5 quedan alineadas con el gateway (master d3e3e7e); la copia en inglés es verbatim. El diccionario de claves se regeneró y explica cada contador de presencia, incluido entradas.

7 de octubre de 2026

Releer lo ya comprado cuesta solo el cargo base durante 24 horas

Nuevo: una consulta por id que tu cuenta ya pagó en las últimas 24 horas se cobra solo con el cargo base de 0.01 créditos. Aplica a GET /v5/entities/{id} y a sus sub-rutas, con cualquier llave de la cuenta. «La misma consulta» es la misma entidad, los mismos códigos y la misma página; el plazo corre desde la primera compra y no se extiende al repetir. Así, un script que se relanza desde el principio no paga dos veces lo que ya trajo.
La relectura trae los datos actuales y la cabecera X-Panadata-Already-Purchased con la fecha de la compra. Su dry_run cotiza el cargo base y agrega already_purchased (purchased_at, expires_at).
No aplica a DAT-SCREEN (/screening o en include), que consulta listas de sanciones en cada llamada, ni a la búsqueda, la resolución o los lotes.

7 de octubre de 2026

Morosidad CSS con la fila del empleador y spec alineado

Corrección: las menciones en el listado de empleadores morosos de la CSS (DAT-RISK) traen la fila del empleador listado: nombre, ruc, numero_patronal, monto_adeudado, cantidad_planillas y condicion, entre otros. Antes traían la publicación mensual, con nombre y ruc siempre en null y sin el monto. Solo los listados de junio-2025, diciembre-2025 y junio-2026 traen montos.
Corrección: GET /v5/entities/{id}/css-morosos ya no adjunta el texto OCR del listado completo a cada ítem (~5 MB por ítem, que hacía fallar la paginación con 502). Cada ítem trae el pdf_url del listado. El schema nuevo CssMorosoMencion describe los ítems de esa ruta y del css_moroso_menciones del detalle.
Las tres copias publicadas del spec v5 quedan alineadas con el gateway (master cab1b14), que también documenta la ventana de relectura (already_purchased en el dry_run); la copia en inglés es verbatim. El diccionario de claves se regeneró.

5 de octubre de 2026

Demo pública con datos ficticios

Nuevo: la demo pública muestra, sin cuenta ni llave, la respuesta real de GET /v5/entities/{id} para 23 empresas y personas ficticias: el resumen, DAT-CORE y DAT-CORE completo. Cada una muestra un caso de los datos reales, desde una sociedad con datos en casi todas las fuentes hasta una sin ningún registro, pasando por un directorio con filas raras del Registro y dos homónimos que solo separa la cédula.

5 de octubre de 2026

Body inválido como 400, filtros de ubicación en inmuebles, updates de edificios por unidad y el modo de prueba

Cambio de comportamiento: un body JSON que no es un objeto (un array, un string, un número) responde 400 invalid_body en POST /v5/resolve, POST /v5/resolve/batch, POST /v5/entities/batch, POST /v5/search/{surface} y POST /v5/gov-entities/resolve. Antes era un 500.
Nuevo: la búsqueda real-estate acepta los filtros lugar, corregimiento y colindante: una frase sin tildes ni mayúsculas, por ejemplo lugar=punta paitilla.
Cambio de contrato: la actualización de un activo (POST /v5/entities/{id}/update con pa_finca_*, pa_ph_* o pa_edif_*) va por la lane prioritaria (lane: user), que se atiende antes que el backfill automático. Un edificio encola una petición por cada unidad viva, y el 202 trae ids, units, enqueued_units y failed_units además del id de la primera. Cada unidad cuenta contra el tope de re-scrapes de la llave, y una llamada encola como mucho 500 unidades (413 too_many_units). En el update de una entidad, si el envío del scrape falla, la respuesta es 502 con retryable: true y no se cobra nada.
Modo de prueba (en preparación): el spec documenta cómo responde el API a las llaves de prueba pk_test_, que todavía no se pueden crear. Nunca se cobran y nunca leen datos reales. GET /v5/entities/{id} con DAT-CORE responde datos ficticios para pa_own_2100000001–pa_own_2100000999, con "mode": "sandbox" en el cuerpo y la cabecera X-Panadata-Mode: sandbox. Las demás rutas responden 403 sandbox_route_not_ready, y ?dry_run=1 cotiza el precio real.
Las tres copias publicadas del spec v5 quedan alineadas con el gateway (master a59694c); la copia en inglés es verbatim. El diccionario de claves se regeneró.

23 de septiembre de 2026

Errores de búsqueda que dicen la verdad y el dry_run del nivel gratuito en entidades

Una respuesta parcial de OpenSearch ya no se cobra como «no existe». Si la búsqueda vuelve con shards fallidos o con timed_out, la API responde 502 search_backend_error en lugar de un 200 con cero resultados cobrado. Lo mismo pasa en una búsqueda de una sola superficie cuyo índice falta. Todo 502 trae la cabecera Retry-After: 5.
retryable dice la verdad. Un filtro con un valor del tipo equivocado (por ejemplo {"monto_min": "abc"}) es 400 invalid_search_query con retryable: false: hay que corregir la consulta, no repetirla. Un bug de nuestro lado es 500 internal_error, también con retryable: false. Los tres códigos comparten el schema nuevo BackendError y ninguno se cobra ni cuenta contra el cupo gratuito.
POST /v5/resolve/batch reintenta una vez una fila que recibió un rechazo por carga (429 / es_rejected_execution); si vuelve a fallar, el 502 es de toda la llamada y no se cobra nada. Una fila cuya consulta se rechaza vuelve con outcome: invalid y el resto del lote se resuelve.
El dry_run de una llave gratuita cotiza en entidades. Trae would_charge: "0" y un bloque free_tier (schema FreeTierQuote): el presupuesto (daily o estimator), counts_as, used / limit / remaining, las cifras del mes y would_exceed. Si la llamada real sería rechazada, trae además would_status, code y reset_at; si el código está fuera del nivel gratuito, locked: true. Cotizar nunca cuenta. La respuesta lleva las cabeceras X-Panadata-Free-Remaining-Today y -Month.
Los enlaces de «paso siguiente» cambian. El upgrade_url de los rechazos a una llave (401 key_expired, 403 free_tier_code_locked, 429 free_tier_limit, 402 estimator_rows_exhausted) apunta a la página de compra, https://platform.panadata.net/facturacion. siguiente_paso.para_ver_los_registros de la ficha DAT-FREE apunta a /docs/precios. Los rechazos sin llave siguen apuntando a /docs/dat-free.
GET /v5/entities/{id} declara también la herramienta MCP quote_investigation, con ejemplos curl de su dry_run por nivel. En el servidor MCP, quote_investigation cotiza aunque la llave gratuita esté en su tope diario (devuelve un techo sin menú), y get_entity acepta inline_limit y summary. Un test de paridad verifica que toda herramienta del MCP aparezca en el spec.
DAT-PROPONENTE sale temporalmente de GET /v5/catalog mientras terminamos de extraer las propuestas. GET /v5/entities/{id}/proponente-dossier sigue respondiendo y cobra 2.50 solo cuando entrega datos.
Las tres copias publicadas del spec v5 quedan alineadas con el gateway (master 6dae8a0); la copia en inglés es verbatim. El diccionario de claves se regeneró.

23 de septiembre de 2026

Actualización de entidades en v5: el update es gratis, se paga la data al entregarla

Nuevo: la actualización de una entidad pasa a v5: POST /v5/entities/{id}/update acepta ids pa_own_*. El update en sí es gratis; con ?include= se indica qué códigos traerá la entrega, y esos códigos se cobran a su precio de lectura v5 —lo mismo que GET /v5/entities/{id}?include=— recién cuando el resultado se entrega. Las secciones que vuelven vacías no se cobran, un update sin include es gratis y, si el scrape falla, no se cobra nada. La billetera tiene que cubrir la entrega al pedirla (402 antes de encolar); ?dry_run=1 la cotiza. Solo llaves con saldo.
El 202 del update de una entidad trae id: pa_ur_<n> y poll. El resultado llega por webhook, si la cuenta lo tiene configurado, y en result de GET /v5/update-requests/pa_ur_<n>, con la misma forma que GET /v5/entities/{id}?include=: ids tipados, country y detalle compacto. Consultar el estado nunca cobra.
La actualización de un activo (finca, PH o edificio) también pasa a ser gratis: deja de cobrar la tarifa base. En los dos casos sigue el tope de re-scrapes por llave (429).
Deprecado: POST /v4/panama/entidades/{id}/update. Sigue funcionando igual —mismo cobro y mismo result v4— y no tiene fecha de apagado; las integraciones nuevas deben usar POST /v5/entities/{id}/update.
Las tres copias publicadas del spec v5 quedan alineadas con el gateway (master 3a4eb48); la copia en inglés es verbatim. El diccionario de claves se regeneró con la forma nueva del 202.

23 de septiembre de 2026

Estado de actualizaciones de activos, resolución por lotes y nivel gratuito

Cambio de contrato: el 202 de POST /v5/entities/{id}/update (re-scrape de un activo) ya no trae update_request_id. Trae id con el id tipado de la petición, pa_aur_<n> — lane automática —, y ningún otro id: las lanes de owner y de activo tienen secuencias separadas, y el entero suelto se consultaba como si fuera de la lane de owner. Si su integración leía update_request_id de ese 202, pase a leer id.
Nuevo: GET /v5/update-requests/{id} consulta el estado de una actualización por id tipado, sin cargo (solo autenticación). pa_ur_<n> (o el entero que devuelve el update de v4) lee la lane de owner con la misma semántica que GET /v4/update_requests/{id}; pa_aur_<n> responde el estado de la fila de jobs-api: queued o running (siga consultando) y luego completed, failed o unknown. Solo estado y timestamps: result es siempre null y los datos refrescados se leen por las rutas v5 normales. La gramática de ids suma los tipos ur y aur.
Cambio de comportamiento: cuando OpenSearch no responde, POST /v5/resolve, POST /v5/resolve/batch, GET /v5/entities y POST /v5/search/{surface} devuelven 502 search_backend_error con retryable: true, sin cobro y sin contar contra el cupo gratuito. Antes la caída se veía como un 200 con cero resultados —se leía como «no existe»— y se cobraba. Reintente ante ese 502.
?dry_run se lee con un único parser en todas las rutas: un valor con espacios (?dry_run=%201) es una cotización en todas partes. Antes el control de acceso lo tomaba como cotización y la ruta como llamada real, lo que se saltaba los topes del nivel gratuito. dry_run es gratis en todo nivel de acceso y cotiza cualquier código sin consumir contadores.
Nuevo: POST /v5/resolve/batch resuelve hasta 100 filas (name, names, ruc o cedula) en una llamada: DAT-RESOLVE por fila válida y la tarifa base una sola vez por petición. Cada fila se clasifica en resolved_exact, ambiguous, unresolved o invalid (las inválidas no se cobran), y with_presence: true agrega cuántas identidades resueltas tienen datos por código DAT. En POST /v5/resolve se suman names (hasta 5 grafías del mismo nombre, un cargo) y top; los candidatos vienen ordenados por confidence, nunca por debajo de 0.5, y un RUC o una cédula escritos con espacios o con DV se normalizan antes de buscar.
Nivel gratuito: el spec documenta los tres niveles de acceso (public sin llave, free con billetera en cero, paid), la ficha DAT-FREE (GET /v5/entities/{id}?include=DAT-FREE, 0 créditos + base), los 429 free_tier_limit con Retry-After y las cabeceras X-Panadata-Tier y X-Panadata-Free-*. El detalle está en Nivel gratuito (DAT-FREE).
Cambio de formato: GET /v5/entities/{id} devuelve por defecto el detalle compacto (summary=compact): imports_summary y exports_summary van por año con las 5 fracciones principales, customs_summary pierde sus copias imports/exports, y fincas/propiedades traen los generales del inmueble con fincas_meta.detail apuntando a /v5/entities/{id}/real-estate, donde vive el historial de gravámenes. Las listas largas se cortan a inline_limit filas (10 por defecto) con un <sección>_meta que apunta al sub-recurso paginado. ?summary=full devuelve las tres secciones como antes; el precio no cambia en ningún modo.
Cada ruta del spec lleva x-mcp-tool (la herramienta MCP que la envuelve) y x-curl-example por nivel de acceso. Las tres copias publicadas del spec v5 (/openapi.v5.en.yml, /openapi.v5.es.yml y /openapi.v5.yml) vuelven a estar alineadas con el gateway (master 9af4caf); la copia en inglés es verbatim.

16 de septiembre de 2026

Entidades de gobierno, actualización de activos y filtros de gravámenes

Nuevo: entidades de gobierno de Panamá como catálogo propio, con el tipo gov en la gramática de ids (pa_gov_7). GET /v5/gov-entities?q= busca una institución por cualquier grafía (tilde, mayúsculas, abreviatura, sigla; q de al menos 3 caracteres), GET /v5/gov-entities/{id} devuelve el detalle —tipo, provincia, todos sus RUC-NT y cada alias con su procedencia— y POST /v5/gov-entities/resolve resuelve una lista de hasta 100 nombres a entidades, un resultado por entrada y en el mismo orden. Los homónimos vuelven como filas separadas con match: ambiguo, nunca fusionados. Las tres rutas cobran solo la tarifa base (resolve: base × N nombres). El mismo id pa_gov_* también resuelve por GET /v5/entities/{id}.
Nuevo: POST /v5/entities/{id}/update dispara un re-scrape asíncrono de un activo (finca, PH o edificio): responde 202 con update_request_id, cobra solo la tarifa base y tiene un tope de re-scrapes por llave (429). Las entidades (pa_own_*) siguen actualizándose por POST /v4/panama/entidades/{id}/update.
La documentación de filtros de POST /v5/search/real-estate se completa: además de codigo_ubicacion y valor_min/_max quedan documentados superficie_min/_max, edificio, floor, unit_label, price_m2_min/_max, sale_value_min/_max, sale_fecha_min/_max y planta_nivel_min/_max, y se suma el ledger de gravámenes: acreedor (acreedores vigentes, nombre canónico), acreedor_historico (cualquier gravamen, incluidos los cancelados) y gravamenes_vigentes_min/_max. Precio y tier: una búsqueda inmobiliaria con cualquier clave del ledger cobra DAT-REALESTATE-LEADS (2.50 créditos + base) y exige tier Pro+; sin esas claves sigue cobrando DAT-REALESTATE-SEARCH (1.25 + base) y está abierta a todos los tiers. dry_run cotiza el SKU que corresponde a los filtros enviados. El grupo gravamen_* (acreedor + estado + monto + fecha sobre una misma hipoteca) está documentado pero todavía responde 400 como filtro desconocido hasta que el índice migre al mapping anidado.
En las surfaces de comercio exterior el filtro hs filtra por prefijo: 8703 trae todas las partidas 8703.*.
Las tres copias publicadas del spec v5 (/openapi.v5.en.yml, /openapi.v5.es.yml y /openapi.v5.yml) vuelven a estar alineadas con el gateway (master e1957bd); la copia en inglés es verbatim.

31 de agosto de 2026

Ids tipados en los resultados de búsqueda y surface de migración

Cambio de formato: en POST /v5/search/{surface}, el campo results[].id devuelve ahora el id público tipado (pa_imp_60023 en vez de 60023) en las surfaces cuyos registros son direccionables: importaciones, exportaciones, marcas, naves, real-estate (pa_finca_ y pa_ph_), real-estate-deeds (pa_relemento_) e immigration (pa_mig_, pa_wp_, pa_visaaut_ y pa_imped_). Ese id se pasa tal cual a GET /v5/entities/{id}, así que encadenar búsqueda y detalle ya no requiere lógica del cliente.
Las demás surfaces (licitaciones, avisos, contraloria, expedientes, sanctions, noticias y planillas) conservan el PK entero.
Una clave de filtro desconocida en /v5/search/{surface} ahora responde 400 con la lista de claves válidas. Antes se ignoraba en silencio y la búsqueda devolvía resultados sin filtrar.
La surface immigration queda disponible también por MCP (herramienta search), con facetas y filtros, la matriz filtro–fuente corregida y advertencias de uso: a la fecha de esta nota los datos de Mitradel estaban congelados al 11 de mayo de 2026 (96,3% de las filas sin movimiento desde antes de esa fecha; hay un re-scrape de puesta al día en curso, así que verifique la frescura de cada fila por su propio fecha_ultimo_movimiento), y se suman los filtros fecha_inicio y fecha_ultimo_movimiento, que existen esté el caso cerrado o no. El detalle migratorio sigue gateado por DAT-LABOR.
Deprecado: el filtro estado de POST /v5/search/immigration —y su faceta by_estado— se retirará del contrato: es un veredicto derivado cuya semántica se invierte según la fuente (en un impedimento, «resuelto» significa que el acto se firmó y notificó, o sea que el impedimento probablemente entró en vigor, no que se levantó; en una visa, «resuelto» sin resultado se lee como aprobada). El campo ya no viene en la tarjeta, ni en el summary ni en el detalle; el filtro se sigue aceptando hasta el retiro, y mientras siga vivo distingue mayúsculas y minúsculas (estado=Resuelto devuelve 0, estado=resuelto devuelve el corpus). Para saber si un caso está abierto o cerrado use fecha_fin, que solo existe en casos cerrados, o los filtros nuevos fecha_inicio y fecha_ultimo_movimiento. Ojo: el veredicto sigue viajando en cada resultado como derived_data.estado_actual y arrastra la misma semántica invertida — se retirará de ahí junto con el filtro, así que no construya sobre ese campo.
Cambio de comportamiento: en GET /v5/entities/{id}/network el parámetro depth pasa de 1 a 2 por defecto. Quien no manda depth recibe ahora también el grafo plano de dos saltos —con quién está conectada la entidad y a través de quién—, una respuesta bastante más grande que antes; si le alcanza la vista histórica sola, pida ?depth=1 de forma explícita. A cambio se elimina la facturación por nivel: toda profundidad cuesta el mismo SKU plano (DAT-NETWORK), así que depth es una perilla de tamaño y no un escalón de precio. El tercer salto (?depth=3) sigue disponible y es mucho más grande: sobre un sujeto real, 303 nodos contra 72.
El servidor MCP lee el catálogo de códigos en vivo desde GET /v5/catalog (26 códigos con sus precios exactos) y se elimina el mirror estático, que podía quedar desactualizado.
Documentado GET /v5/entities/{id}/proponente-dossier (DAT-PROPONENTE). Además, GET /v5/entities/{id}/immigration pasa a cubrir cuatro fuentes: a los permisos de trabajo y los movimientos migratorios se suman ahora las visas autorizadas y los impedimentos, en la misma ficha. Con una salvedad: los impedimentos se enlazan a la persona por nombre —la fuente no publica pasaporte ni cédula—, cada elemento de impedimentos[] trae un match {key, score} con la procedencia del enlace, y la cobertura es parcial (hoy alrededor del 5% de los impedimentos de la fuente llegan a una persona). Es una coincidencia de nombre, no una identidad confirmada: verifíquela antes de actuar, y tenga presente que un impedimentos[] vacío significa «no lo enlazamos», no «no tiene impedimento». Para descartar, busque por nombre en POST /v5/search/immigration con source=impedimento.
pa_visacons_ se retira de la gramática de ids: la fuente consular no es cosechable.

26 de junio de 2026

Catálogo de Ecuador: 12 niveles para organizaciones

El catálogo público de Ecuador se precisa a 12 niveles (antes 13), tras verificar la cobertura real contra la fuente. Se retira entity_events, que no tiene fuente en Ecuador y no devuelve datos.
El precio de DAT-ALL en Ecuador ($0.85) no cambia. El alcance sigue siendo solo organizaciones jurídicas.

20 de junio de 2026

Servidor MCP remoto y onboarding instantáneo

La API de Panadata ya está disponible como herramientas MCP (Model Context Protocol) para casos de uso con LLM y agentes, con una nueva página de capacidades y una guía rápida "Conéctese por MCP".
Al confirmar la cuenta se aprovisiona automáticamente una llave API y se otorgan 10 créditos gratis; no caducan, y se renuevan cada 30 días mientras el saldo esté en cero.
Configuración MCP personalizada lista para copiar desde el panel.
El paquete completo DAT-ALL deja de incluir el screening internacional (DAT-SCREEN — sanciones internacionales y coincidencias PEP), que ahora se cobra por separado; su precio queda en $1.41 por entidad en Panamá ($0.85 en Ecuador).

28 de mayo de 2026

Documentación de webhooks y actualizaciones asíncronas

Nueva guía Actualizaciones asíncronas y webhooks con el flujo completo: POST de trigger, body firmado con HMAC-SHA256, fallback por GET y matriz de estados.
OpenAPI ahora documenta POST /v4/panama/entidades/{id}/update y GET /v4/update_requests/{id} con tres schemas nuevos.
Cobertura: solo Panamá hoy. Ecuador y Colombia siguen siendo read-only.

27 de mayo de 2026

Ecuador disponible (read-only)

Cobertura inicial de Ecuador para organizaciones: búsqueda por nombre o RUC y detalle por ID en /v4/ecuador/entidades.
Tres códigos disponibles: CHK-BIN, DAT-CORE y DAT-ALL ($0.85 por entidad), sobre 13 niveles de datos.
Solo lectura: las actualizaciones asíncronas siguen siendo exclusivas de Panamá.

7 de abril de 2026

Webhooks y sandbox interactivo

Sandbox autenticado con flujo guiado: búsqueda por nombre, RUC e ID con respuestas reales de la API.
Sistema de webhooks para solicitudes de actualización de entidades con firma criptográfica. Sistema independiente del código de producto DAT-HOOK, que es pull (devuelve entity_events en la respuesta del GET) y no tiene relación con el delivery de notificaciones por POST.
Hub de documentación rediseñado con ViewComponents y navegación lateral.

23 de marzo de 2026

Framework de precios v4

Catálogo de códigos de producto ampliado de 12 a 17 SKUs activos con framework de precios basado en valor; el paquete completo DAT-ALL pasa a $1.81 por entidad.
Especificaciones OpenAPI sincronizadas con el API Gateway de producción.
Parche de seguridad: Devise 5.0.3 (GHSA-57hq-95w6-v4fc).

16 de marzo de 2026

Referencia API bilingüe

Especificaciones OpenAPI v4 en español e inglés.
Metadatos de discoverability para agentes de IA (link rel=describedby).
Sincronización del nombre de llave API hacia DynamoDB para logging estructurado.

10 de marzo de 2026

Localización al español

Toda la interfaz de la plataforma traducida al español.
Copiar al portapapeles en llaves API y sandbox.
Nuevo favicon de Panadata.

3 de marzo de 2026

Documentación interactiva

Referencia API interactiva con Scalar (OpenAPI 3.0).
Correcciones en el flujo de checkout de Stripe (CORS, Turbo).

27 de febrero de 2026

Dashboard de uso

Gráfico de uso con ejes duales (costo y solicitudes), tooltips y selector de período.
Resumen de estadísticas con totales del período seleccionado.

10 de febrero de 2026

Lanzamiento de la plataforma v4

Plataforma self-service para Panamá: registro, autenticación, llaves API, saldo prepago y consumo.
GET /v4/panama/entidades — búsqueda por nombre o RUC.
GET /v4/panama/entidades/{id}?include= — detalle y enriquecimiento.
12 códigos de producto activos: CHK-BIN, DAT-CORE, DAT-HOOK, DAT-GOV, DAT-BIZ, DAT-ASSET, DAT-TRADE, DAT-DOC, DAT-RISK, DAT-PROC, DAT-NEWS, DAT-LEGAL. Paquete completo DAT-ALL a $1.35.
Panel de llaves API con creación y revocación, sincronización a DynamoDB.
Compra de saldo prepago vía Stripe Checkout.
Wallet con créditos atómicos en DynamoDB.