KydHub (Know Your Data Hub) es un hub de identidad y datos verificados. Permite que una empresa como Acme consulte datos autorizados de personas y empresas sin tener que recolectar, validar y mantener esa información por su cuenta.
La idea es simple: la persona o empresa mantiene sus datos en KydHub, KydHub actúa como fuente confiable, y cada integración recibe sólo los campos que necesita y que está autorizada a leer.
Importante: no necesitás usar el login de KydHub para usar la Data API. Si Acme ya tiene su propio sistema de usuarios, puede conservarlo y usar KydHub sólo para consultar datos autorizados desde su backend.
Capacidades disponibles ahora
Consultar una persona
Acme puede consultar datos autorizados de Bob Carter usando su KYD, por ejemplo BOB.CARTER, o un ID público per_....
Direcciones de persona
Una empresa puede pedir sólo las direcciones registradas que necesita, como dirección de envío, facturación o residencia, según autorización.
Consultar una empresa
Acme puede consultar datos autorizados de otra empresa por KYD empresarial o ID público comp_00000000-0000-4000-8000-000000000042, sin usar KydHub como directorio abierto.
Direcciones de empresa
También puede consultar direcciones o ubicaciones registradas de una empresa, cuando el caso de uso lo permite.
Login con KWID opcional
Si querés delegar login o SSO, KydHub ofrece OAuth/OIDC. Si no, podés saltarlo y usar sólo Data API.
Seguridad avanzada
API keys server-only, webhooks firmados y cifrado post-cuántico opcional para payloads sensibles.
Integración por stack
Recetas para Python/FastAPI, Node.js/Express, Go y desktop apps como Tauri, Electron y Rust.
La Data API pública es sólo lectura. Las empresas no modifican datos de personas ni administran API keys, OAuth clients o webhooks por API pública; eso se hace desde el portal de KydHub.
Para empresas y usuarios
KydHub conecta dos necesidades: empresas que necesitan datos confiables y personas que quieren controlar qué información comparten.
Para empresas
Consultás datos verificados sin volver a pedirlos manualmente.
Pedís sólo los campos necesarios para tu caso de uso.
Usás API keys server-to-server desde el backend de Acme.
Podés conservar tu login actual y usar KydHub sólo como Data API.
Si querés, también podés ofrecer Login con KWID/OIDC.
Recibís eventos firmados por webhook cuando el flujo lo requiere.
Para personas
Mantenés tu identidad y datos en un lugar controlado.
Autorizás qué empresa puede leer qué información.
Evitás repetir nombre, perfil o direcciones en cada integración.
Las empresas leen datos autorizados, pero no modifican tus datos por API pública.
Tu KYD, por ejemplo BOB.CARTER, funciona como identificador verificable.
Servicios disponibles en esta etapa
Servicio
Qué permite
Quién lo usa
Persona
Consultar datos autorizados de una persona, como identidad o perfil básico.
Backend de Acme con API key.
Direcciones de persona
Consultar direcciones registradas de una persona cuando el flujo y los permisos lo permiten.
Backend de Acme con API key.
Empresa
Consultar datos autorizados de otra empresa usando KYD empresarial o ID público comp_00000000-0000-4000-8000-000000000042.
Backend de Acme con API key.
Direcciones de empresa
Consultar direcciones o ubicaciones registradas de una empresa.
Backend de Acme con API key.
Secuencia típica: Acme crea una API key en el portal, guarda el secreto en su backend, pide sólo los campos que necesita y muestra en su sistema únicamente la respuesta autorizada por KydHub.
Límite intencional: por ahora la API pública no crea, edita ni elimina personas, empresas, direcciones, API keys, OAuth clients ni webhooks. Esas acciones administrativas viven en el portal.
Conceptos clave
Estos nombres aparecen en casi todos los ejemplos. La idea es que sepas qué identifica a quién antes de copiar una petición.
KYD / KWIDIdentificador público legible. Para una persona usamos ejemplos como BOB.CARTER. Para empresas se usa el KYD empresarial que KydHub tenga registrado.
person_idID público opaco de persona, por ejemplo per_.... Es estable para integraciones y no revela UUIDs internos.
company_idID público opaco de una empresa, por ejemplo comp_00000000-0000-4000-8000-000000000042. Se usa cuando ya conocés la empresa en KydHub.
fieldsLista exacta de campos que querés leer. KydHub recomienda pedir lo mínimo necesario: menos campos, menos exposición y menos fricción de autorización.
scopePermiso que habilita una familia de campos o acciones. La API pública de datos usa scopes de lectura; las acciones administrativas viven en el portal.
grantAutorización activa que permite a una empresa leer ciertos datos de una persona. Si no existe o no cubre el campo pedido, KydHub debe rechazar la consulta.
Antes de empezar
Antes de hacer una llamada, separá tres cosas: el ambiente donde vas a probar, la credencial que autoriza a el backend de Acme y el identificador del recurso que querés consultar.
Ambientes y URLs
Qué
Valor
Cuándo se usa
Dashboard dev
https://dev.dashboard.kydhub.com
Superficie browser del dashboard KydHub en dev.
Auth / endpoints OAuth dev
https://dev.auth.kydhub.com
Host canónico objetivo para endpoints OAuth/OIDC/Login. Hasta completar el rollout, leé los endpoints exactos desde discovery.
Docs dev
https://dev.docs.kydhub.com
Documentación developer en dev.
Base Data API
https://dev.api.kydhub.com/api/v1
Consultas server-to-server con API key. No requiere que uses OAuth de KydHub.
Issuer OIDC
https://dev.kydhub.com
Issuer estable. Validá que el iss del token coincida con este valor.
Fuente de verdad para endpoints de authorize, token, UserInfo y JWKS.
Autenticación mínima para Data API
Para consultar datos, Acme envía una API key desde su backend. Esa key identifica a la empresa y permite aplicar límites, scopes, auditoría y permisos.
Reglas de presentación de valores autorizados: nombres, direcciones, texto, fechas y locale.
Formatos de respuesta: perfil vs presentación
KydHub separa tres decisiones distintas para que la integración no sea ambigua:
Atributo
Qué decide
Ejemplo
fields
Qué datos pide Acme.
name, addresses.shipping, profile.occupation
response_profile
Cómo se organiza el JSON completo.
standard, summary, compliance, audit
format
Cómo se presentan los valores autorizados.
apellido primero, mayúsculas, sin tildes, dirección postal, fecha localizada
format es presentación de datos. No concede permisos, no agrega campos y no reemplaza scopes ni grants. Si un campo no está autorizado, KydHub no lo devuelve aunque exista una regla de formato para ese campo.
Perfiles de respuesta (response_profile)
Estos perfiles no cambian la capitalización ni el contenido de nombres/direcciones; sólo cambian la estructura general del payload.
response_profile
Uso
Diferencia real
standard
Integración normal, SDKs, storage y webhooks.
Devuelve los campos pedidos en estructura canónica bajo fields.
summary
UI, cards, checkout, soporte y listados.
Devuelve un resumen legible y menos profundo para mostrar rápido.
compliance
Onboarding, revisión formal, verificación y evidencias.
Agrupa datos formales/verificados y señales de compliance; no es “formato de texto”.
audit
Logs, debugging y evidencia de acceso.
Devuelve trazabilidad de request/autorización/resultado; no expande datos de negocio innecesarios.
Formato de presentación (format)
El cliente puede pedir que KydHub preformatee valores para no implementar esas reglas en cada aplicación.
Si el servicio todavía no tiene un data grant aprobado, la Data API responde con un error accionable. No devuelve UUIDs internos ni usa el wrapper del portal.
{
"status": "error",
"error": {
"code": "data_grant_required",
"person_kyd": "BOB.CARTER",
"service_name": "acme-checkout",
"requested_fields": ["name"],
"required_permissions": [
{"permission": "person.identity:read", "reason": "Required to identify the requested person in the Data API flow."},
{"permission": "person.name:read", "reason": "Required to read the requested field: name."}
],
"resolution": {
"action": "request_data_grant",
"endpoint": "POST /api/v1/data-grants/requests",
"request_body": {
"subject_type": "person",
"subject_kyd": "BOB.CARTER",
"requested_scopes": ["person.identity:read", "person.name:read"],
"purpose": "Allow acme-checkout to read the person's name.",
"external_reference": "acme-checkout"
}
}
}
}
Cuando la respuesta es exitosa, person_id siempre usa prefijo per_; nunca se expone el UUID interno de la tabla persona.
Granularidad del campo nombre:name devuelve el nombre completo autorizado. name.primary devuelve primer nombre + primer apellido para UI compacta. name.parts devuelve arrays estructurados: given_names, middle_names, family_names. format.names controla presentación/orden/capitalización; no debe eliminar silenciosamente segundos nombres o segundos apellidos.
Dato base usado en los ejemplos:
{
"given_names": ["Bob", "José"],
"middle_names": ["de la Cruz"],
"family_names": ["O'Neill", "García"],
"full_name": "Bob José de la Cruz O'Neill García"
}
format.names
Salida formatted
Uso recomendado
as_recorded
Bob José de la Cruz O'Neill García
Máxima fidelidad al dato guardado.
given_first
Bob José de la Cruz O'Neill García
UI normal orientada a usuario final.
surname_first_comma
O'Neill García, Bob José de la Cruz
CRM, reportes, listas administrativas.
surname_first_space
O'Neill García Bob José de la Cruz
Sistemas antiguos que no aceptan coma.
locale_title_case
Bob José de la Cruz O'Neill García
Capitalización respetando idioma/región.
upper
BOB JOSÉ DE LA CRUZ O'NEILL GARCÍA
Documentos o reportes en mayúsculas conservando tildes.
lower
bob josé de la cruz o'neill garcía
Normalización visual o matching blando.
ascii
Bob Jose de la Cruz ONeill Garcia
Sistemas sin Unicode o búsquedas simples.
ascii_upper
BOB JOSE DE LA CRUZ ONEILL GARCIA
Sistemas legacy/regulatorios que requieren ASCII mayúscula.
Para usar la Data API, Acme necesita una API key creada desde el portal de KydHub. Esa key identifica a la empresa que consulta, aplica límites de uso y permite auditar qué campos se solicitaron.
Dónde conseguir una API key
Paso
Qué hacer
Resultado
1
Entrá al portal de KydHub con tu usuario.
Accedés a tu espacio personal o empresarial.
2
Cambiá al contexto de empresa, por ejemplo Acme.
Las credenciales quedan asociadas a esa empresa.
3
Abrí Company → API Access → API keys.
Ves las API keys activas, revocadas y sus fechas.
4
Creá una nueva API key y elegí si expira o nunca caduca.
KydHub genera el secreto completo una sola vez.
5
Copiá el secreto y guardalo en el backend de Acme o secret manager.
Ya podés llamar la Data API desde tu servidor.
Copiala en ese momento: KydHub muestra el secreto completo una sola vez. Después sólo vas a ver el nombre, prefijo, estado y metadata de la key.
Cómo usar la API key
La API key viaja en el header X-API-KEY. No identifica a una persona final; identifica a la empresa integradora que está consultando datos autorizados.
No pegues el valor real en código, logs, tickets ni documentación.
X-API-KEY
Header de autenticación server-to-server.
Debe enviarlo el backend de Acme, nunca el navegador.
person_kyd
KYD público de la persona consultada.
Puede cambiarse por person_id si ya lo tenés.
fields
Campos exactos que querés leer.
Pedí lo mínimo necesario para tu caso de uso.
Diferencia entre credenciales
Credencial
Para qué sirve
Dónde debe vivir
¿Puede ir al browser?
API key
Consultar Data API desde backend.
Backend o secret manager.
No.
OAuth client_id
Iniciar Login con KWID/OIDC.
Frontend/backend según flujo.
Sí, no es secreto.
OAuth client_secret
Autenticar un cliente OAuth confidencial.
Backend o secret manager.
No.
Webhook secret
Verificar firmas de eventos entrantes.
Backend receptor de webhooks.
No.
Límites Company Free
Área
Límite
Qué implica
API keys
2 activas
Podés tener dos keys activas por empresa; revocá una antes de crear una tercera.
Expiración
Opcional
Una key puede no expirar o tener fecha de vencimiento.
Rate limit
60/min
Si superás el límite, la API responde con error de rate limit.
Uso diario
2.000/día
Diseñado para integraciones iniciales y pilotos controlados.
Buenas prácticas: nombrá cada key según su uso, por ejemplo acme-production-data-api o acme-sandbox-test, y rotala si alguien del equipo deja de necesitar acceso.
Integración por stack
Recetas de integración: esta sección también está disponible en la vista HTML navegable, en Markdown formateado y en Markdown crudo. Incluye Python/FastAPI, Node.js/Express, Go, Tauri, Electron y Rust.
Estas recetas muestran cómo conectar el backend o la app de Acme con KydHub. La regla principal es separar bien los tipos de integración: la Data API usa API key server-to-server; OAuth/OIDC es opcional para Login con KWID; las apps de escritorio deben usar navegador del sistema + PKCE y nunca distribuir secretos.
Regla de seguridad: no pongas KYDHUB_API_KEY, client_secret ni webhook secrets en frontend, binarios desktop, repositorios o logs. En desktop usá PKCE y delegá llamadas server-to-server a tu backend cuando necesites proteger secretos.
Qué patrón usar según tu stack
Stack
Uso recomendado
Secreto permitido
Notas
Python / FastAPI
Backend server-to-server para Data API, OAuth callback y webhooks.
Sí, en variables de entorno/secret manager.
Ideal para validar tokens, guardar API keys y verificar HMAC.
Node.js / Express
Backend server-to-server para Data API, OAuth callback y webhooks.
Sí, en variables de entorno/secret manager.
Buen punto de entrada para apps web SPA/SSR.
Go
Backend o servicio interno de alto rendimiento.
Sí, en variables de entorno/secret manager.
Útil para integraciones B2B, workers y servicios empresariales.
Tauri
Desktop app con navegador del sistema + PKCE.
No dentro del binario.
Usá callback custom scheme o loopback local; Data API sensible vía backend.
Electron
Desktop app con navegador del sistema + PKCE.
No dentro del paquete de la app.
No uses client_secret en main/renderer.
Rust
CLI/desktop/backend con PKCE o servicio server-side.
Depende del tipo de app.
Servidor Rust puede guardar secrets; app distribuida no.
Python / FastAPI · consultar persona
Este ejemplo expone un endpoint interno de Acme que consulta datos autorizados de Bob Carter en KydHub. La API key vive sólo en el backend.
Las apps de escritorio distribuidas no deben incluir secretos. Para Login con KWID usá navegador del sistema, PKCE, state y nonce. Para Data API sensible, la app debe llamar a tu backend y tu backend llama a KydHub.
Desktop: el intercambio de code por tokens debe validar state, usar el mismo code_verifier y verificar nonce en el ID token. No guardes tokens indefinidamente si la app no los necesita.
HTTP QUERY (RFC 10008) y compatibilidad
QUERY es el método canónico para consultas complejas read-only de KydHub. Es seguro, idempotente y reintentable. La consulta se describe mediante contenido JSON; no modifica el estado de personas ni empresas.
Contrato
Valor
Operaciones canónicas
QUERY /api/v1/persons/query y QUERY /api/v1/companies/query
Headers requeridos
X-API-KEY, Content-Type: application/json; usa Accept: application/json para negociación explícita.
Discovery
OPTIONS devuelve Allow: QUERY, POST, OPTIONS y Accept-Query: application/json.
Límite del body
1 MiB. El contenido excedido devuelve 413.
Política privada de caché
Cache-Control: no-store, private. El rollout inicial deshabilita caché compartida.
Compatibilidad
POST /api/v1/*/query es un alias temporal deprecado que invoca el mismo pipeline de autorización y consulta. Se conserva hasta que Gate C pruebe soporte de QUERY en clientes, proxy, WAF y gateway.
Contrato de errores: 400 metadatos ausentes/inconsistentes o JSON malformado; 401 API key ausente/inválida; 403 autorización denegada; 406 representación no aceptable; 413 body excedido; 415 media type no soportado; 422 JSON válido con contenido no procesable.
Compatibilidad de intermediarios: usa el alias POST solo cuando un cliente o intermediario desplegado no pueda emitir/reenviar QUERY. La preparación para producción requiere evidencia end-to-end de Gate C.
QUERYConsultar persona
Consultar persona es una operación Data API segura, idempotente y read-only. Usa QUERY porque el request lleva contenido JSON de consulta estructurado: identificadores, servicio interno, campos solicitados, perfil de respuesta y formato de presentación.
Regla de verbos: usá GET para una lectura simple con un identificador; usá QUERY /query para una lectura segura e idempotente con contenido JSON estructurado. El alias POST deprecado queda solo para compatibilidad temporal.
Store it for future references; do not use internal UUIDs.
status
Operation result.
success means the requested authorized fields were returned.
service_name
Service slug received in the request.
Useful for audit and debugging.
response_profile_used
Applied response profile.
Confirms the response profile processed by KydHub.
format_used
Applied value-presentation options.
Do not treat it as authorization; it only describes formatting.
fields
Authorized returned fields.
Only fields approved by API key, scopes and grant/consent are present.
Errores de autorización
{
"status": "error",
"error": {
"code": "data_grant_required",
"message": "The service does not have an approved data grant to read the requested person fields.",
"person_kyd": "BOB.CARTER",
"service_name": "acme-checkout"
}
}
Privacidad por defecto: KydHub does not return unrequested or unauthorized fields. Do not design integrations that depend on extra data.
QUERYConsultar direcciones de una persona
Una empresa puede consultar direcciones registradas de una persona cuando el caso de uso lo justifica y existe autorización para esos campos. Por ejemplo, Acme puede necesitar la ciudad y país de Bob Carter para completar un flujo de envío o facturación.
Pedí lo mínimo: si Acme sólo necesita ciudad y país, no debe pedir calle, código postal ni dirección completa. KydHub permite que el request sea explícito campo por campo.
Acme no tiene autorización activa para leer direcciones de Bob.
Pedí consentimiento o ajustá el flujo para no requerir dirección.
field_not_allowed
Algún campo addresses.* no está cubierto por scopes/grant.
Quitá el campo o solicitá el permiso correcto.
address_not_available
No hay dirección registrada/autorizada para los campos pedidos.
Mostrá una alternativa en tu flujo; no inventes dirección.
person_not_found
El person_kyd o person_id no existe.
Verificá el identificador recibido.
Privacidad de direcciones: una dirección puede ser más sensible que un nombre. No pidas line1, line2 o código postal si tu integración sólo necesita país o ciudad.
QUERYConsultar empresa
Consultar empresa es el equivalente empresarial de Query person: una consulta credencializada, read-only, con body JSON. Su método canónico es QUERY /api/v1/companies/query porque RFC 10008 define solicitudes seguras e idempotentes con contenido de consulta estructurado.
Sin directorio abierto: la empresa consultante debe conocer el identificador objetivo y pasar los tres gates: empresa/API key activa, scopes requeridos y grant/relación/base explícita de acceso.
success means the requested authorized groups were returned.
company_kyd
Known public company KYD.
Use it as the readable identifier for the company.
company_id
Public company ID for the company.
Store it only as a public identifier; do not infer internal database IDs.
service_name
Service slug received in the request.
Useful for audit and debugging.
fields.identity
Authorized identity fields.
Requires company.identity:read.
fields.profile
Authorized profile fields.
Requires company.profile:read.
fields.locations
Authorized public location rows.
Requires company.locations:read.
Lecturas simples de recurso
Para lecturas simples con un solo identificador en path, el backend también expone endpoints GET orientados a recurso. Usalos cuando no se necesita un request JSON complejo:
GET /api/v1/companies/{company_identifier}
GET /api/v1/companies/{company_identifier}/profile
GET /api/v1/companies/{company_identifier}/locations
Seguridad: ni QUERY ni las lecturas GET son búsqueda pública/directorio abierto. Toda lectura de empresa es credencializada, con scopes, auditoría y gate de relación/autorización.
QUERYConsultar direcciones de una empresa
Acme también puede consultar direcciones o ubicaciones registradas de otra empresa cuando necesita validar datos de facturación, operación, sucursales o cobertura. Igual que el resto de la Data API, la consulta es de sólo lectura y requiere pedir campos concretos.
Diferencia clave: una dirección de empresa describe una entidad comercial o sus ubicaciones. No es una dirección personal y no debe mezclarse con addresses.* de una persona.
No existe empresa con ese company_kyd o company_id.
Verificá el identificador por un canal autorizado.
company_locations_scope_required
La API key no tiene permiso para leer ubicaciones de empresa.
Solicitá/habilitá company.locations:read; los planes limitan capacidad, no la categoría de dato.
location_not_available
No hay ubicación disponible/autorizada para los campos pedidos.
Mostrá una alternativa o pedí menos campos.
field_not_allowed
Algún campo locations.* no está permitido.
Quitá el campo o pedí el scope correspondiente.
Sin datos privados por defecto: no documentes ni esperes emails, teléfonos, responsables internos o datos administrativos de una ubicación salvo que el contrato explícitamente los habilite.
Login con KWID / OAuth OIDC opcional
Login con KWID permite que Acme use KydHub como proveedor de identidad mediante OAuth 2.0 y OpenID Connect. Es útil cuando querés delegar login, SSO o verificación de identidad en KydHub.
Recordatorio: OAuth/OIDC no es obligatorio para usar la Data API. Si Acme ya tiene su propio login, puede conservarlo y usar sólo API keys server-to-server para consultar datos autorizados.
Cuándo usarlo y cuándo saltarlo
Situación
Recomendación
Por qué
Acme ya tiene login propio
Podés saltar OAuth de KydHub.
Usá Data API con API key desde backend para consultar datos autorizados.
Acme quiere Login con KWID
Usá OAuth 2.0 + OIDC.
KydHub autentica al usuario y devuelve tokens/claims verificables.
Aplicación web con backend
Usá Authorization Code + PKCE y cliente confidencial si aplica.
El backend puede guardar secretos de forma segura.
Aplicación móvil o escritorio
Usá PKCE y tratala como cliente público salvo que haya backend.
No pongas client_secret dentro de una app distribuida.
GET1 · Iniciar Login con KWID
Para qué sirve: Acme redirige al usuario a KydHub para que confirme su identidad con KWID. Cuando vuelve al callback de Acme, el backend recibe un code que luego canjea por tokens.
# redirigí al usuario a KydHub
GET https://dev.auth.kydhub.com/oauth/authorize
?client_id=kh_client_…
&redirect_uri=https://app.acme.example/callback
&response_type=code
&scope=openid kwid email profile company:read
&state=RANDOM
&code_challenge=…&code_challenge_method=S256
Parámetro
¿Obligatorio?
Qué es
client_id
Sí
El ID de la app de Acme en KydHub.
redirect_uri
Sí
A dónde vuelve el usuario. Debe coincidir exacto con el registrado.
response_type
Sí
Siempre code.
scope
Sí
Datos que pedís, separados por espacio.
state
Sí
Valor random anti-CSRF; lo validás al volver.
code_challenge
Sí
PKCE: el hash de tu code_verifier (método S256).
nonce
Opcional
Recomendado: lo validás en el id_token para evitar replays.
login_hint
Opcional
Pre-llená el KWID (ej. BOB.CARTER).
prompt
Opcional
login fuerza re-autenticación aunque haya SSO.
Tip: guardá state, nonce y el code_verifier antes de redirigir — los vas a necesitar cuando el usuario vuelva.
POST2 · Verificación por email
Si el usuario no tiene una sesión activa en KydHub, el primer /authorize puede volver con error=login_required y verification_required. Esto es un estado intermedio esperado, no un error fatal. Acme debe mostrar “Revisá tu email” y arrancar la verificación desde su backend.
El email es el canal de verificación. No construyas vos la URL de /oauth/login/verify ni abras el consentimiento directo: KydHub lo hostea tras el magic link. Usá expires_at para el contador.
Apps públicas: si la integración es móvil o escritorio, no distribuyas un client_secret dentro de la app. Usá PKCE y/o un backend propio para proteger secretos.
POST3 · Canjear el code por el token
Para qué sirve: cuando KydHub te devuelve al redirect_uri con un code, tu backend lo cambia por los tokens. Acá sí entra el client_secret.
Brecha actual: name/given_name/family_name y picture pueden venir vacíos (caer al KWID) hasta que KydHub complete los nombres reales. Para el nombre confiable, usá la Data API.
Claims por scope
Cada scope que pedís habilita ciertos claims:
Scope
Claims que devuelve
openid
sub, iss, aud, exp, iat, auth_time (y nonce si lo mandaste).
kwid
kwid.
email
email, email_verified.
profile
name, given_name, family_name, picture (sujeto a la brecha de arriba).
Errores OAuth: intermedios vs terminales
Los intermedios se resuelven siguiendo el flujo; los terminales requieren reiniciar.
↻ Intermedios
verification_required — iniciá verificación por email.
pending_consent / consent_required — esperá el consentimiento hosteado.
login_required — iniciá login si no hay SSO.
Terminales
invalid_grant — code expirado/usado, redirect o PKCE mismatch.
invalid_verification_identifier — KWID inválido.
fresh_authentication_required — reiniciá con prompt=login.
access_denied — el usuario canceló.
Referencia rápida Data API
Esta referencia reúne las capacidades canónicas de Data API. Usala como índice rápido; para detalles completos, leé cada sección específica.
Regla contractual: la Data API es credencializada y de sólo lectura. No crea, edita ni elimina personas, empresas, direcciones, API keys, OAuth clients ni webhooks.
Autorización en tres niveles: cada request necesita (1) una empresa activa con una X-API-KEY server-side válida, (2) los scopes requeridos, y (3) un grant activo, consentimiento, relación autorizada u otra base explícita de acceso para los datos devueltos.
Endpoints canónicos
Endpoint
Capacidad
Identificador
Autorización
QUERY /api/v1/persons/query
Consultar datos autorizados de persona.
person_kyd o person_id.
X-API-KEY, service_name, scopes y grant/consentimiento activo.
QUERY /api/v1/companies/query
Consultar identidad autorizada de empresa.
company_kyd conocido o identificador de empresa soportado.
X-API-KEY, company.identity:read y base válida de acceso.
QUERY /api/v1/companies/query
Consultar campos autorizados de perfil de empresa.
company_kyd conocido o identificador de empresa soportado.
X-API-KEY, company.profile:read y base válida de acceso.
QUERY /api/v1/companies/query
Consultar ubicaciones autorizadas de empresa.
company_kyd conocido o identificador de empresa soportado.
X-API-KEY, company.locations:read y base válida de acceso.
GET https://dev.api.kydhub.com/api/v1/companies/ACME.SUPPLIER
X-API-KEY: $KYDHUB_API_KEYGET https://dev.api.kydhub.com/api/v1/companies/ACME.SUPPLIER/profile
X-API-KEY: $KYDHUB_API_KEYGET https://dev.api.kydhub.com/api/v1/companies/ACME.SUPPLIER/locations?lang=es
X-API-KEY: $KYDHUB_API_KEY
Reglas de autorización
Regla
Detalle
Empresa solicitante
KydHub deriva la empresa solicitante desde la X-API-KEY server-only. No confíes en identificadores del body como identidad del solicitante.
Scopes
Los scopes describen qué pide la integración. Los planes limitan capacidad; scopes más grants/consentimiento deciden qué datos se devuelven.
Grants y consentimiento
Los datos de persona y datos protegidos de empresa requieren grant activo, consentimiento, relación autorizada u otra base explícita de acceso.
service_name
Requerido para query person. Usá un slug ASCII en minúsculas que cumpla ^[a-z0-9]+(?:-[a-z0-9]+)*$, por ejemplo acme-checkout.
Sin directorio abierto
Query company es para empresas conocidas y autorizadas. No es búsqueda abierta ni browsing de empresas.
IDs públicos
Usá per_... y comp_00000000-0000-4000-8000-000000000042 en contratos client-facing; nunca expongas UUIDs internos.
Errores
Si falta API key, scope, grant, relación o autorización del campo, la API falla cerrado y no expone datos.
POSTWebhooks
Los webhooks permiten que Acme reciba eventos firmados desde KydHub cuando algo relevante ocurre. Son opcionales: si tu integración sólo necesita consultar datos bajo demanda, podés usar la Data API sin webhooks.
Cuándo usarlos: usá webhooks cuando tu backend necesita enterarse de cambios, aprobaciones, revocaciones o entregas sin estar consultando la API constantemente.
Flujo general
Paso
Qué ocurre
Responsable
1
Acme registra una URL receptora en el portal de KydHub.
Acme
2
KydHub genera o muestra el secreto de firma del webhook.
KydHub
3
Cuando ocurre un evento, KydHub envía un POST al backend de Acme.
KydHub
4
Acme valida la firma HMAC antes de procesar el evento.
Acme
5
Acme guarda el event_id para evitar procesar duplicados.
Actualizar estado interno y habilitar consulta Data API.
grant.rejected
Una persona rechazó la solicitud.
Mostrar alternativa o pedir menos datos.
grant.revoked
Una autorización fue revocada.
Dejar de usar datos que dependan de ese grant.
webhook.delivery.failed
KydHub no pudo entregar un evento tras intentos.
Revisar disponibilidad del endpoint receptor.
Reintentos, idempotencia y límites
Tema
Regla
Recomendación
Respuesta exitosa
Respondé 2xx sólo después de validar firma y guardar el evento.
No hagas trabajo lento antes de responder; enviá a una cola si hace falta.
Reintentos
KydHub puede reintentar entregas fallidas.
Procesá por event_id para evitar duplicados.
Company Free
1 webhook activo y 1000 intentos de entrega por mes.
Los reintentos cuentan contra el límite mensual.
Seguridad
El secreto de webhook vive sólo en backend/secret manager.
No lo pongas en frontend, logs ni documentación pública.
No confíes sólo en la URL: cualquier endpoint público puede recibir requests. Procesá únicamente eventos con firma válida, timestamp aceptable y event_id no procesado.
Seguridad, scopes, grants y límites
La seguridad de KydHub combina credenciales server-only, un catálogo completo de scopes solicitables, autorizaciones activas y límites de uso. La regla base es simple: la Data API es de sólo lectura y devuelve únicamente los scopes/campos específicos que fueron pedidos y autorizados.
Reglas principales
Hacé
Guardá API keys, OAuth secrets y webhook secrets sólo en backend o secret manager.
Pedí sólo los campos necesarios en fields.
Validá scopes y grants antes de depender de una respuesta.
Verificá firmas de webhook con HMAC y comparación timing-safe.
Rotá credenciales cuando una persona del equipo pierde acceso.
Mostrá alternativas cuando falte autorización o un campo no esté disponible.
No hagas
No pongas API keys en browser, apps móviles, repositorios ni documentación.
No pongas client_secret dentro de una app distribuida.
No uses KydHub como directorio abierto de empresas.
No inventes datos si KydHub no devuelve un campo.
No ignores grant_required o field_not_allowed.
No intentes modificar personas, empresas, direcciones, API keys, OAuth clients o webhooks por la Data API pública.
Modelo de autorización
Capa
Qué valida
Ejemplo
API key
Qué empresa está llamando y si la key está activa.
Acme llama con X-API-KEY.
Plan/límites
Cuántas credenciales, requests o entregas puede usar la empresa.
Company Free permite 2 API keys activas.
Scopes
Qué familias de datos puede leer una credencial.
person.addresses:read.
Grant
Qué persona/empresa autorizó la lectura y para qué campos.
Bob Carter autorizó lectura de identidad y direcciones.
Fields
Qué atributos exactos pide el request.
["full_name", "addresses.city"].
Orden mental: una respuesta existe sólo si la API key es válida, el scope existe en el catálogo, el usuario u otra base válida lo autorizó, los límites de uso lo permiten y el campo fue pedido explícitamente.
Catálogo de scopes y aprobación del usuario
KydHub publica un catálogo completo y granular de scopes. Las empresas Pro y Enterprise pueden solicitar cualquier scope publicado; KydHub no bloquea una categoría de dato por plan. El usuario aprueba o rechaza exactamente los scopes de datos personales solicitados. Los planes limitan capacidad operativa: volumen de requests, rate limits, API keys, OAuth clients, webhooks, retención, soporte y SLA.
Verificación de identidad y envío después de aprobación explícita del usuario.
Scopes actuales documentados
Scope
Permite leer
Usado en
person.identity:read
Identificadores y nombre básico de persona.
Consultar persona.
person.profile:read
Perfil básico autorizado de persona.
Consultar persona.
person.addresses:read
Direcciones registradas/autorizadas de persona.
Direcciones de persona.
company.identity:read
Identidad básica de empresa.
Consultar empresa.
company.profile:read
Perfil autorizado de empresa.
Consultar empresa.
company.locations:read
Ubicaciones/direcciones registradas de empresa.
Direcciones de empresa.
webhooks.events:read
Eventos webhook si se exponen diagnósticos.
Diagnóstico/operación.
usage:read
Uso y consumo de API si el contrato lo habilita.
Diagnóstico/operación.
audit:read
Eventos de auditoría permitidos.
Diagnóstico/operación.
Company Free limits
Área
Límite
Notas
Personas por empresa
2 total
1 owner/founder y 1 collaborator.
API keys
2 activas
Pueden no expirar; expiración opcional.
API rate limit
60 requests/min
Aplicado por empresa/API key según contrato operativo.
API daily limit
2.000 requests/día
Diseñado para pilotos e integraciones iniciales.
Webhooks
1 activo
1000 intentos de entrega/mes; los retries cuentan.
OAuth / Apps
1 connected app, 1 OAuth client
Hasta 3 redirect URIs.
Audit logs
7 días
Retención básica.
Soporte
Basic / best-effort
Sin SLA contractual.
Operaciones permitidas y prohibidas
Tipo
Estado
Explicación
Leer datos autorizados de persona
Permitido
Con API key, scope de catálogo, grant/consentimiento/base válida activa y fields explícitos.
Leer direcciones autorizadas de persona
Permitido
Con permiso de direcciones.
Leer datos autorizados de empresa
Permitido
Con company_kyd o company_id conocido.
Leer ubicaciones autorizadas de empresa
Permitido
Con company.locations:read.
Crear/modificar personas por API pública
Prohibido
La persona modifica sus datos dentro de KydHub.
Crear/modificar empresas por API pública
Prohibido
Se administra desde el portal.
Administrar API keys/OAuth/webhooks por API pública
Prohibido
Por ahora se hace desde el portal.
Buscar empresas sin identificador
Prohibido
KydHub no debe funcionar como directorio abierto.
Respuesta segura ante falta de permiso
{
"error": "field_not_allowed",
"message": "One or more requested fields are not allowed for this API key or grant.",
"fields": ["addresses.line1"]
}
Fail closed: si falta scope, grant o campo autorizado, KydHub debe responder sin exponer el dato. La integración debe reducir campos, pedir autorización o continuar con una alternativa.
Errores y troubleshooting
Esta sección resume los errores más comunes al integrar KydHub. La recomendación general es no inventar datos ni continuar como si la respuesta hubiera sido exitosa: cada error indica una acción concreta para corregir credenciales, permisos, identificadores o configuración.
Regla práctica: si un error menciona credenciales, revisá el portal de Acme. Si menciona grant o field, pedí menos datos o solicitá autorización. Si menciona webhook, validá firma, endpoint e idempotencia.
Formato recomendado de error
{
"error": "field_not_allowed",
"message": "One or more requested fields are not allowed for this API key or grant.",
"request_id": "req_01HVEXAMPLE",
"fields": ["addresses.line1"]
}
Atributo
Qué significa
Cómo usarlo
error
Código estable del error.
Usalo para lógica de UI/backend.
message
Explicación legible.
Mostrala sólo si no expone datos internos; podés mapearla a copy propio.
request_id
ID de correlación.
Incluilo al pedir soporte o revisar logs.
fields
Campos afectados, cuando aplica.
Útil para remover campos o pedir autorización correcta.
API keys y autenticación
Error
Qué significa
Cómo resolverlo
missing_api_key
No llegó el header X-API-KEY.
Enviá la API key desde el backend de Acme. No la envíes desde browser.
invalid_api_key
La key no existe, fue revocada, expiró o está mal copiada.
Creá o rotá una key desde Company → API Access.
api_key_limit_reached
La empresa ya tiene el máximo de API keys activas.
En Company Free, revocá una key activa antes de crear otra.
rate_limit_exceeded
Se superó el límite de requests por minuto.
Reducí frecuencia, agregá backoff y revisá límites del plan.
daily_limit_exceeded
Se superó el límite diario.
Esperá reinicio de ventana o consultá upgrade/contrato.
Identificadores y recursos
Error
Qué significa
Cómo resolverlo
person_not_found
No existe persona para ese person_kyd o person_id.
Verificá el identificador. No intentes adivinar identidades.
company_not_found
No existe empresa para ese company_kyd o company_id.
Confirmá el identificador por canal autorizado; KydHub no es directorio abierto.
invalid_identifier
El identificador tiene formato inválido.
Usá BOB.CARTER, per_..., company_kyd o comp_00000000-0000-4000-8000-000000000042 según corresponda.
address_not_available
No hay dirección de persona disponible/autorizada.
Pedí menos campos o mostrale al usuario una alternativa.
location_not_available
No hay ubicación empresarial disponible/autorizada.
Continuá sin ubicación o pedí un campo menos sensible.
Scopes, grants y fields
Error
Qué significa
Cómo resolverlo
grant_required
No hay autorización activa para leer esos datos.
Iniciá el flujo de autorización o pedí campos que no requieran ese grant.
grant_revoked
La autorización existía pero fue revocada.
Dejá de usar esos datos y solicitá nueva autorización si corresponde.
field_not_allowed
Uno o más campos no están permitidos por scope/grant.
Quitá campos, pedí menos datos o solicitá permisos adecuados.
scope_required
La API key no tiene el scope necesario.
Solicitá/habilitá el scope exacto. El usuario decide la autorización de datos personales; los planes limitan volumen/capacidad.
company_scope_required
Falta scope de lectura de empresa.
Usá scopes como company.identity:read o company.profile:read.
company_locations_scope_required
Falta permiso para ubicaciones de empresa.
Revisá si la key tiene company.locations:read.
OAuth / Login con KWID
Error
Qué significa
Cómo resolverlo
login_required
El usuario no tiene sesión activa.
Mostrá el flujo de verificación o redirigí a KydHub.
verification_required
Debe completar verificación por email/magic link.
No lo trates como fallo fatal; mostrale “Revisá tu email”.
invalid_redirect_uri
La URL callback no coincide exactamente con la registrada.
Registrá https://app.acme.example/callback o la URL real exacta.
invalid_client
client_id o secreto incorrecto.
Revisá el OAuth client en el portal. No pongas secrets en apps públicas.
invalid_grant
El code expiró, ya fue usado o no corresponde al verifier.
Reiniciá login y validá PKCE/state.
invalid_token
Token inválido, expirado o con firma incorrecta.
Validá issuer, audience, expiración y JWKS.
Webhooks
Error
Qué significa
Cómo resolverlo
webhook_signature_invalid
La firma HMAC no coincide.
Usá el raw body exacto y el secreto correcto; compará timing-safe.
webhook_timestamp_expired
El timestamp es demasiado viejo.
Rechazá el evento y revisá reloj/sincronización.
webhook_duplicate_event
El event_id ya fue procesado.
No lo reproceses; devolvé 2xx si ya quedó persistido.
webhook_delivery_failed
KydHub no pudo entregar el evento.
Revisá disponibilidad pública, TLS y respuesta 2xx del endpoint.
webhook_limit_reached
Se alcanzó el límite de webhooks activos o entregas.
En Company Free hay 1 webhook activo y 1000 intentos/mes.
Cifrado post-cuántico opcional
Error
Qué significa
Cómo resolverlo
pq_encryption_not_enabled
La capa no está habilitada para la empresa.
Usá Data API normal o pedí habilitación contractual.
unknown_key_id
El kid no existe o fue rotado.
Registrá/obtené la clave pública vigente.
decrypt_failed
No se pudo descifrar o falló AEAD.
No proceses contenido; reintentá con clave válida.
unsupported_algorithm
La suite criptográfica no está soportada.
Negociá una suite soportada o desactivá esta capa.
Soporte: al pedir ayuda, compartí request_id, endpoint, ambiente y hora aproximada. Nunca compartas API keys, client secrets, webhook secrets, tokens ni payloads con PII.
Agent-readable / matriz de endpoints
Esta sección resume la integración de KydHub en formato compacto para agentes, equipos técnicos y documentación interna. No reemplaza las secciones anteriores: sirve como mapa rápido para implementar sin perder las reglas de seguridad.
Uso recomendado: si un agente o developer necesita integrar KydHub, primero debe leer esta matriz y luego ir a la sección detallada del endpoint que va a usar.
Resumen operativo
Elemento
Valor
Nota
Ambiente sandbox/dev
https://dev.api.kydhub.com/api/v1
Usado para pruebas y documentación actual.
Auth Data API
X-API-KEY
Sólo backend/secret manager. Nunca browser.
Empresa ejemplo
Acme
Empresa integradora ficticia.
Persona ejemplo
Bob Carter / BOB.CARTER
Persona ficticia para ejemplos.
Empresa consultada ejemplo
ACME.SUPPLIER
KYD empresarial ficticio.
Modelo de API
Sólo lectura
No crea, modifica ni elimina datos por API pública.
Matriz de capacidades actuales
Capacidad
Endpoint didáctico
Identificadores
Scopes típicos
Consultar persona
QUERY /api/v1/persons/query
person_kyd o person_id
person.identity:read, person.profile:read
Consultar direcciones de persona
QUERY /api/v1/persons/query
person_kyd o person_id
person.addresses:read
Consultar identidad de empresa
QUERY /api/v1/companies/query
company_kyd conocido o identificador de empresa soportado.
company.identity:read
Consultar ubicaciones de empresa
QUERY /api/v1/companies/query
company_kyd conocido o identificador de empresa soportado.
API key válida + scope de catálogo + grant/consentimiento/base válida + fields explícitos.
Leer direcciones autorizadas de persona
Sí
person.addresses:read y autorización activa.
Leer campos autorizados de empresa
Sí
company_kyd o company_id conocido.
Leer ubicaciones autorizadas de empresa
Sí
company.locations:read.
Usar Login con KWID/OIDC
Opcional
Sólo si Acme decide delegar login/verificación.
Recibir webhooks firmados
Opcional
Webhook registrado en portal + secreto HMAC.
Operaciones prohibidas para agentes
Operación
Estado
Regla
Modificar datos de personas por API pública
No
La persona administra sus datos dentro de KydHub.
Modificar empresas por API pública
No
La empresa se administra desde el portal.
Crear API keys por API pública
No
Las API keys se crean desde el portal.
Crear OAuth clients por API pública
No
Los OAuth clients se administran desde el portal.
Buscar empresas sin identificador
No
KydHub no es directorio abierto.
Exponer secrets en código o logs
Nunca
Usar variables de entorno o secret manager.
Checklist para implementar
#
Validación
Resultado esperado
1
Crear API key en portal.
Secret guardado en backend/secret manager.
2
Hacer request mínimo de persona.
Respuesta contiene sólo campos pedidos/autorizados.
3
Probar falta de scope/campo no permitido.
Error seguro tipo field_not_allowed.
4
Si hay OAuth, validar state, nonce y JWKS.
Login seguro y tokens verificados.
5
Si hay webhooks, validar HMAC e idempotencia.
Eventos firmados y sin procesamiento duplicado.
6
Documentar errores esperados en la integración.
UX con alternativas y sin inventar datos.
Instrucción para agentes: no generes endpoints, scopes ni campos no documentados aquí. Si falta una capacidad, tratala como no disponible hasta que KydHub la documente explícitamente.
Cifrado post-cuántico opcional
KydHub puede ofrecer una capa opcional de cifrado híbrido post-cuántico para payloads especialmente sensibles. Esta capa protege el cuerpo del mensaje además de HTTPS/TLS, pero no reemplaza autenticación, autorización, scopes, grants, auditoría ni firmas.
Idea simple: TLS protege el transporte. El cifrado post-cuántico opcional protege también el payload para que sólo el receptor esperado pueda abrirlo, incluso si el mensaje queda almacenado o pasa por sistemas intermedios.
Cuándo usarlo
Situación
Recomendación
Motivo
Integración estándar de Data API
No es obligatorio.
TLS, API key, scopes y grants ya son la base de seguridad.
Payloads con PII sensible
Puede activarse si el contrato lo habilita.
Agrega confidencialidad del body además del canal TLS.
Webhooks con datos sensibles
Puede usarse junto con firma HMAC.
La firma verifica integridad/origen; el cifrado protege contenido.
Cliente sin soporte criptográfico
No lo actives todavía.
Primero integrá Data API normal y luego agregá esta capa.
Qué no reemplaza
Control
Sigue siendo obligatorio
Por qué
TLS/HTTPS
Sí
Protege el canal de transporte.
API key
Sí
Identifica a la empresa que llama.
OAuth/OIDC
Sí, si usás Login con KWID
Autentica usuarios y emite claims/tokens.
Scopes y grants
Sí
Deciden qué datos pueden leerse.
Firma de webhooks
Sí
Verifica origen e integridad del evento.
Auditoría
Sí
Permite rastrear quién pidió qué y cuándo.
Cómo funciona a alto nivel
Paso
Qué pasa
Resultado
1 · Clave pública
El receptor publica o registra una clave pública de cifrado.
El emisor sabe con qué clave proteger el payload.
2 · KEM post-cuántico
El emisor encapsula un secreto usando ML-KEM/Kyber.
Se obtiene un secreto compartido resistente al modelo post-cuántico.
3 · ECDH clásico
Se genera además un secreto X25519 efímero.
Defensa híbrida clásica + post-cuántica.
4 · Derivación
Ambos secretos entran a HKDF.
Se deriva una clave simétrica para cifrar.
5 · AEAD
El payload se cifra con AES-256-GCM u otro AEAD aprobado.
Lo usa el receptor para recuperar el secreto compartido.
ecdh_public_key
Clave pública efímera X25519 del emisor.
Participa en la derivación híbrida.
nonce
Nonce usado por el cifrado AEAD.
No debe repetirse para la misma clave.
ciphertext
Payload cifrado.
Contiene los datos reales protegidos.
aad
Datos autenticados no cifrados.
Vincula el payload con método, path, evento o contexto.
Errores y fallback
Error
Qué significa
Qué hacer
pq_encryption_not_enabled
La empresa no tiene habilitada esta capa.
Usá Data API normal o solicitá habilitación.
unknown_key_id
El kid no existe o fue rotado.
Obtené/registrá la clave pública actual.
decrypt_failed
El payload no pudo descifrarse o la autenticación AEAD falló.
No proceses el contenido; registrá el error y reintentá con una clave válida.
unsupported_algorithm
El algoritmo no está soportado por una de las partes.
Negociá una suite soportada o desactivá esta capa.
No lo uses para saltar permisos: el cifrado post-cuántico no autoriza datos. Si falta API key, scope o grant, KydHub debe fallar cerrado antes de construir o aceptar payloads sensibles.
Los endpoints de identidad KWID (OAuth 2.0 + PKCE) y la Data API server-to-server, con parámetros y ejemplos de request/response para cada endpoint.
El client_secret y la X-API-KEY viven solo en tu backend.
Autorización en tres niveles: las lecturas de Data API requieren empresa activa con API key, los scopes requeridos y un grant activo, consentimiento, relación autorizada u otra base explícita de acceso. Query company es para empresas conocidas y autorizadas, no búsqueda abierta ni directorio abierto.