Descargar .md

Empezar

Qué resuelve KydHub

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.

Ver recetas de integración

Qué no hace la API pública

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

ServicioQué permiteQuién lo usa
PersonaConsultar datos autorizados de una persona, como identidad o perfil básico.Backend de Acme con API key.
Direcciones de personaConsultar direcciones registradas de una persona cuando el flujo y los permisos lo permiten.Backend de Acme con API key.
EmpresaConsultar 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 empresaConsultar 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éValorCuándo se usa
Dashboard devhttps://dev.dashboard.kydhub.comSuperficie browser del dashboard KydHub en dev.
Auth / endpoints OAuth devhttps://dev.auth.kydhub.comHost canónico objetivo para endpoints OAuth/OIDC/Login. Hasta completar el rollout, leé los endpoints exactos desde discovery.
Docs devhttps://dev.docs.kydhub.comDocumentación developer en dev.
Base Data APIhttps://dev.api.kydhub.com/api/v1Consultas server-to-server con API key. No requiere que uses OAuth de KydHub.
Issuer OIDChttps://dev.kydhub.comIssuer estable. Validá que el iss del token coincida con este valor.
Discovery OIDChttps://dev.kydhub.com/.well-known/openid-configurationFuente 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.

QUERY https://dev.api.kydhub.com/api/v1/persons/query
X-API-KEY: $KYDHUB_API_KEY
Content-Type: application/json
AtributoQué esRegla
X-API-KEYSecreto server-to-server de la empresa.Nunca lo pongas en frontend, apps móviles, repositorios ni documentación pública.
Content-TypeFormato del cuerpo de la petición.Usá application/json en ejemplos con body JSON.

Identificadores que vas a usar

AtributoEjemploCuándo usarlo
person_kydBOB.CARTERCuando conocés el KYD/KWID público de la persona.
person_idper_...Cuando ya tenés el ID público opaco de esa persona.
company_kydACME.SUPPLIERCuando consultás datos de una empresa por su KYD empresarial.
company_idcomp_00000000-0000-4000-8000-000000000042Cuando ya tenés el ID público opaco de esa empresa.
fields["full_name", "addresses.city"]Lista de campos solicitados. Pedí sólo lo necesario para tu flujo.
service_name"acme-checkout"Slug técnico del servicio interno que hace la consulta. Debe ser minúscula ASCII con guiones.
response_profile"standard"Estructura del JSON completo: standard, summary, compliance o audit.
format{ "names": "surname_first_comma", "addresses": "postal" }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:

AtributoQué decideEjemplo
fieldsQué datos pide Acme.name, addresses.shipping, profile.occupation
response_profileCómo se organiza el JSON completo.standard, summary, compliance, audit
formatCó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_profileUsoDiferencia real
standardIntegración normal, SDKs, storage y webhooks.Devuelve los campos pedidos en estructura canónica bajo fields.
summaryUI, cards, checkout, soporte y listados.Devuelve un resumen legible y menos profundo para mostrar rápido.
complianceOnboarding, revisión formal, verificación y evidencias.Agrupa datos formales/verificados y señales de compliance; no es “formato de texto”.
auditLogs, 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.

{
  "fields": ["name", "addresses.shipping", "profile.occupation", "created_at"],
  "response_profile": "standard",
  "format": {
    "names": "surname_first_comma",
    "addresses": "multiline",
    "text": "locale_title_case",
    "dates": "localized_datetime",
    "locale": "es-US",
    "include_raw": true
  }
}

Respuesta cuando falta autorizació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.

Respuesta esperada:

{
  "person_id": "per_7Q9M2K4R",
  "person_kyd": "BOB.CARTER",
  "response_profile_used": "standard",
  "format_used": {
    "names": "surname_first_comma",
    "addresses": "multiline",
    "text": "locale_title_case",
    "dates": "localized_datetime",
    "locale": "es-US",
    "include_raw": true
  },
  "fields": {
    "name": {
      "raw": "Bob José de la Cruz O'Neill García",
      "formatted": "O'Neill García, Bob José de la Cruz"
    },
    "addresses": {
      "shipping": {
        "raw": {
          "line1": "1200 Brickell Ave",
          "line2": "Suite 800",
          "city": "Miami",
          "region": "FL",
          "postal_code": "33131",
          "country": "US"
        },
        "formatted": "1200 Brickell Ave\nSuite 800\nMiami, FL 33131\nUS"
      }
    },
    "profile": {
      "occupation": {
        "raw": "software engineer",
        "formatted": "Software engineer"
      }
    },
    "created_at": {
      "raw": "2026-06-30T18:40:00Z",
      "formatted": "30/06/2026 18:40 UTC"
    }
  }
}

Formatos propuestos para nombres

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.namesSalida formattedUso recomendado
as_recordedBob José de la Cruz O'Neill GarcíaMáxima fidelidad al dato guardado.
given_firstBob José de la Cruz O'Neill GarcíaUI normal orientada a usuario final.
surname_first_commaO'Neill García, Bob José de la CruzCRM, reportes, listas administrativas.
surname_first_spaceO'Neill García Bob José de la CruzSistemas antiguos que no aceptan coma.
locale_title_caseBob José de la Cruz O'Neill GarcíaCapitalización respetando idioma/región.
upperBOB JOSÉ DE LA CRUZ O'NEILL GARCÍADocumentos o reportes en mayúsculas conservando tildes.
lowerbob josé de la cruz o'neill garcíaNormalización visual o matching blando.
asciiBob Jose de la Cruz ONeill GarciaSistemas sin Unicode o búsquedas simples.
ascii_upperBOB JOSE DE LA CRUZ ONEILL GARCIASistemas legacy/regulatorios que requieren ASCII mayúscula.
initialsBJDCONGAvatares o vistas ultracompactas.
initials_dottedB. J. O. G.Avatares, firma compacta o UI.

Ejemplo de request:

{
  "fields": ["name"],
  "format": {
    "names": "ascii_upper",
    "include_raw": true
  }
}

Respuesta:

{
  "name": {
    "raw": "Bob José de la Cruz O'Neill García",
    "formatted": "BOB JOSE DE LA CRUZ ONEILL GARCIA",
    "format_used": "ascii_upper"
  }
}

Formatos propuestos para direcciones

Dato base usado en los ejemplos:

{
  "line1": "1200 Brickell Ave",
  "line2": "Suite 800",
  "city": "Miami",
  "region": "FL",
  "postal_code": "33131",
  "country": "US"
}
format.addressesSalida formattedUso recomendado
as_recorded1200 Brickell Ave, Suite 800, Miami, FL, 33131, USFidelidad al registro original.
single_line1200 Brickell Ave, Suite 800, Miami, FL 33131, USCards, checkout, dashboards y tablas.
multiline1200 Brickell Ave\nSuite 800\nMiami, FL 33131\nUSPDFs, documentos y pantallas con bloque postal.
postal1200 Brickell Ave\nSuite 800\nMiami FL 33131\nUNITED STATESEnvíos físicos y logística según país.
compactMiami, FL, USPerfil, búsqueda o listado resumido.
uppercase1200 BRICKELL AVE, SUITE 800, MIAMI, FL 33131, USEtiquetas y sistemas que piden mayúscula.
ascii_upperAV. JOSE MARIA MORELOS #123, MERIDA, YUCATAN, MXDirecciones con tildes para sistemas legacy.

Ejemplo con postal:

{
  "address": {
    "formatted": "1200 Brickell Ave\nSuite 800\nMiami FL 33131\nUNITED STATES",
    "format_used": "postal",
    "country_format_used": "US"
  }
}

Formatos propuestos para texto general y metadata

Aplica a campos como profile.occupation, company.display_name, industry, city, region o labels visibles.

Dato base:

Inteligencia Artificial & Automatización
format.textSalida formattedUso recomendado
preserveInteligencia Artificial & AutomatizaciónMantener valor original.
upperINTELIGENCIA ARTIFICIAL & AUTOMATIZACIÓNReportes o UI en mayúscula.
lowerinteligencia artificial & automatizaciónNormalización visual.
locale_title_caseInteligencia artificial & automatizaciónTítulos legibles respetando idioma.
asciiInteligencia Artificial & AutomatizacionSistemas sin soporte completo Unicode.
ascii_upperINTELIGENCIA ARTIFICIAL & AUTOMATIZACIONLegacy, matching o exportaciones rígidas.
sluginteligencia-artificial-automatizacionURLs, keys, anchors o integraciones internas.

Formatos propuestos para fechas

Dato base:

2026-06-30T18:40:00Z
format.datesSalida formattedUso recomendado
iso2026-06-30T18:40:00ZAPIs, storage e interoperabilidad.
date2026-06-30Reportes por día.
datetime2026-06-30 18:40:00 UTCLogs legibles.
localized_date30/06/2026UI localizada.
localized_datetime30/06/2026 18:40 UTCUI localizada con hora.

Error por formato inválido

{
  "error": "invalid_format",
  "message": "Unsupported presentation format.",
  "field": "format.names",
  "allowed_formats": [
    "as_recorded",
    "given_first",
    "surname_first_comma",
    "surname_first_space",
    "locale_title_case",
    "upper",
    "lower",
    "ascii",
    "ascii_upper",
    "initials",
    "initials_dotted"
  ]
}

API keys y credenciales

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

PasoQué hacerResultado
1Entrá al portal de KydHub con tu usuario.Accedés a tu espacio personal o empresarial.
2Cambiá al contexto de empresa, por ejemplo Acme.Las credenciales quedan asociadas a esa empresa.
3Abrí Company → API Access → API keys.Ves las API keys activas, revocadas y sus fechas.
4Creá una nueva API key y elegí si expira o nunca caduca.KydHub genera el secreto completo una sola vez.
5Copiá 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.

curl -X QUERY https://dev.api.kydhub.com/api/v1/persons/query \
  -H "X-API-KEY: $KYDHUB_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"person_kyd":"BOB.CARTER","fields":["full_name"]}'
AtributoQué significaRegla de uso
$KYDHUB_API_KEYVariable de entorno con el secreto real de Acme.No pegues el valor real en código, logs, tickets ni documentación.
X-API-KEYHeader de autenticación server-to-server.Debe enviarlo el backend de Acme, nunca el navegador.
person_kydKYD público de la persona consultada.Puede cambiarse por person_id si ya lo tenés.
fieldsCampos exactos que querés leer.Pedí lo mínimo necesario para tu caso de uso.

Diferencia entre credenciales

CredencialPara qué sirveDónde debe vivir¿Puede ir al browser?
API keyConsultar Data API desde backend.Backend o secret manager.No.
OAuth client_idIniciar Login con KWID/OIDC.Frontend/backend según flujo.Sí, no es secreto.
OAuth client_secretAutenticar un cliente OAuth confidencial.Backend o secret manager.No.
Webhook secretVerificar firmas de eventos entrantes.Backend receptor de webhooks.No.

Límites Company Free

ÁreaLímiteQué implica
API keys2 activasPodés tener dos keys activas por empresa; revocá una antes de crear una tercera.
ExpiraciónOpcionalUna key puede no expirar o tener fecha de vencimiento.
Rate limit60/minSi superás el límite, la API responde con error de rate limit.
Uso diario2.000/díaDiseñ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

StackUso recomendadoSecreto permitidoNotas
Python / FastAPIBackend 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 / ExpressBackend 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.
GoBackend o servicio interno de alto rendimiento.Sí, en variables de entorno/secret manager.Útil para integraciones B2B, workers y servicios empresariales.
TauriDesktop app con navegador del sistema + PKCE.No dentro del binario.Usá callback custom scheme o loopback local; Data API sensible vía backend.
ElectronDesktop app con navegador del sistema + PKCE.No dentro del paquete de la app.No uses client_secret en main/renderer.
RustCLI/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.

import os
import httpx
from fastapi import FastAPI, HTTPException

app = FastAPI()
KYDHUB_BASE_URL = os.getenv("KYDHUB_BASE_URL", "https://dev.api.kydhub.com/api/v1")
api_key = os.getenv("KYDHUB_API_KEY", "set-in-secret-manager")

@app.get("/internal/kydhub/person/{person_kyd}")
async def get_person(person_kyd: str):
    payload = {
        "person_kyd": person_kyd,
        "service_name": "acme-checkout",
        "fields": ["full_name", "profile.display_name"],
    }
    headers = {
        "X-API-KEY": api_key,
        "Content-Type": "application/json",
    }
    async with httpx.AsyncClient(timeout=10) as client:
        response = await client.request("QUERY", f"{KYDHUB_BASE_URL}/api/v1/persons/query", json=payload, headers=headers)
    if response.status_code >= 400:
        raise HTTPException(status_code=response.status_code, detail=response.json())
    return response.json()

Node.js / Express · consultar empresa

Este ejemplo consulta datos autorizados de una empresa por company_kyd. La API key queda en el backend Express.

import express from "express";

const app = express();
app.use(express.json());

const KYDHUB_BASE_URL = process.env.KYDHUB_BASE_URL ?? "https://dev.api.kydhub.com/api/v1";
const apiKey = process.env.KYDHUB_API_KEY ?? "set-in-secret-manager";

app.post("/internal/kydhub/company", async (req, res) => {
  const response = await fetch(${KYDHUB_BASE_URL}/api/v1/companies/query, {
    method: "QUERY",
    headers: {
      "X-API-KEY": apiKey,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      company_kyd: req.body.company_kyd,
      service_name: "acme-supplier-review",
      fields: ["legal_name", "status", "profile.industry"]
    })
  });

  const body = await response.json();
  res.status(response.status).json(body);
});

Go · consultar direcciones de empresa

Go funciona muy bien para servicios internos, workers o integraciones B2B. Este ejemplo consulta ubicaciones de una empresa usando company_kyd.

package main

import (
  "bytes"
  "encoding/json"
  "net/http"
  "os"
  "time"
)

func queryCompanyLocations(companyKYD string) (*http.Response, error) {
  baseURL := os.Getenv("KYDHUB_BASE_URL")
  if baseURL == "" { baseURL = "https://dev.api.kydhub.com/api/v1" }

  payload := map[string]any{
    "company_kyd": companyKYD,
    "service_name": "acme-supplier-review",
    "fields": []string{"locations.city", "locations.country"},
  }
  body, err := json.Marshal(payload)
  if err != nil { return nil, err }

  req, err := http.NewRequest("QUERY", baseURL+"/api/v1/companies/query", bytes.NewReader(body))
  if err != nil { return nil, err }
  req.Header.Set("X-API-KEY", os.Getenv("KYDHUB_API_KEY"))
  req.Header.Set("Content-Type", "application/json")

  client := &http.Client{Timeout: 10 * time.Second}
  return client.Do(req)
}

Desktop apps · Tauri, Electron y Rust

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.

OpciónUsoRedirect URISecreto
Custom schemeApp registrada como handler.acme://oauth/callbackNo usar client_secret.
Loopback localApp levanta callback temporal.http://127.0.0.1:{port}/callbackNo usar client_secret.
Backend brokerDesktop habla con backend de Acme.Callback web de Acme.El backend sí puede guardar secretos.

Electron · abrir Login con KWID

import { shell } from "electron";
import crypto from "node:crypto";

const state = crypto.randomUUID();
const nonce = crypto.randomUUID();
const codeVerifier = crypto.randomBytes(32).toString("base64url");
const codeChallenge = crypto.createHash("sha256").update(codeVerifier).digest("base64url");

const url = new URL("https://dev.auth.kydhub.com/oauth/authorize");
url.searchParams.set("client_id", "acme_desktop_client");
url.searchParams.set("redirect_uri", "acme://oauth/callback");
url.searchParams.set("response_type", "code");
url.searchParams.set("scope", "openid kwid profile");
url.searchParams.set("state", state);
url.searchParams.set("nonce", nonce);
url.searchParams.set("code_challenge", codeChallenge);
url.searchParams.set("code_challenge_method", "S256");

shell.openExternal(url.toString());

Tauri / Rust · abrir navegador del sistema

use open;
use url::Url;

fn start_kydhub_login(code_challenge: &str, state: &str, nonce: &str) -> anyhow::Result<()> {
    let mut url = Url::parse("https://dev.auth.kydhub.com/oauth/authorize")?;
    url.query_pairs_mut()
        .append_pair("client_id", "acme_desktop_client")
        .append_pair("redirect_uri", "acme://oauth/callback")
        .append_pair("response_type", "code")
        .append_pair("scope", "openid kwid profile")
        .append_pair("state", state)
        .append_pair("nonce", nonce)
        .append_pair("code_challenge", code_challenge)
        .append_pair("code_challenge_method", "S256");

    open::that(url.as_str())?;
    Ok(())
}
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.

ContratoValor
Operaciones canónicasQUERY /api/v1/persons/query y QUERY /api/v1/companies/query
Headers requeridosX-API-KEY, Content-Type: application/json; usa Accept: application/json para negociación explícita.
DiscoveryOPTIONS devuelve Allow: QUERY, POST, OPTIONS y Accept-Query: application/json.
Límite del body1 MiB. El contenido excedido devuelve 413.
Política privada de cachéCache-Control: no-store, private. El rollout inicial deshabilita caché compartida.
CompatibilidadPOST /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.

Request

QUERY https://dev.api.kydhub.com/api/v1/persons/query
X-API-KEY: $KYDHUB_API_KEY
Content-Type: application/json

{
  "person_kyd": "BOB.CARTER",
  "service_name": "acme-checkout",
  "fields": ["name"],
  "response_profile": "standard",
  "format": {
    "names": "given_first",
    "locale": "en-US",
    "include_raw": false
  }
}

Atributos del request

AtributoObligatorioSignificadoRegla
X-API-KEYYesServer-only API key for the requesting company.Identifies the caller company; never expose it in browser/mobile clients.
person_kydYesKnown public KYD/KWID of the person.Example: BOB.CARTER. The current backend requires this field.
service_nameYesInternal service slug making the query.Must match ^[a-z0-9]+(?:-[a-z0-9]+)*$, e.g. acme-checkout.
fieldsOptionalRequested person fields.Defaults to identity. Each field must pass API key, scope and grant/consent checks.
response_profileOptionalOverall response profile requested by the client.Currently echoed as response_profile_used; examples use standard.
formatOptionalPresentation options for authorized values.Formatting never grants extra fields or bypasses authorization.

Response

{
  "person_kyd": "BOB.CARTER",
  "person_id": "per_7Q9M2K4R",
  "status": "success",
  "service_name": "acme-checkout",
  "response_profile_used": "standard",
  "format_used": {
    "names": "given_first",
    "addresses": "as_recorded",
    "text": "preserve",
    "dates": "iso",
    "locale": "en-US",
    "include_raw": false
  },
  "fields": {
    "name": {
      "formatted": "Bob Carter",
      "format_used": "given_first"
    }
  }
}

Atributos del response

AtributoSignificadoCómo usarlo
person_kydPublic person KYD/KWID.Use it as a human-readable identifier.
person_idOpaque public person ID derived by KydHub.Store it for future references; do not use internal UUIDs.
statusOperation result.success means the requested authorized fields were returned.
service_nameService slug received in the request.Useful for audit and debugging.
response_profile_usedApplied response profile.Confirms the response profile processed by KydHub.
format_usedApplied value-presentation options.Do not treat it as authorization; it only describes formatting.
fieldsAuthorized 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.

Petición por KYD de persona

QUERY https://dev.api.kydhub.com/api/v1/persons/query
X-API-KEY: $KYDHUB_API_KEY
Content-Type: application/json

{
  "person_kyd": "BOB.CARTER",
  "service_name": "acme-shipping",
  "fields": [
    "addresses.type",
    "addresses.city",
    "addresses.region",
    "addresses.country",
    "addresses.postal_code"
  ]
}

Atributos de la petición

AtributoObligatorioQué significaRegla
person_kydUno de dosKYD/KWID público de la persona, como BOB.CARTER.Usalo si conocés el alias público de la persona.
person_idUno de dosID público opaco de la persona, como per_....Usalo si ya fue devuelto por KydHub en una consulta previa.
service_nameSlug técnico del servicio que pide la dirección.Ejemplo: acme-shipping o acme-billing.
fieldsCampos de dirección que querés leer.Debe incluir sólo atributos necesarios y autorizados.

Campos de dirección habituales

CampoQué devuelveCuándo pedirlo
addresses.typeTipo de dirección, por ejemplo shipping, billing o registered.Cuando necesitás distinguir uso de la dirección.
addresses.line1Línea principal de la dirección.Sólo si necesitás dirección completa para operar.
addresses.line2Complemento, departamento, piso o referencia.Opcional; pedilo sólo si tu flujo lo usa.
addresses.cityCiudad o localidad.Útil para envío, cobertura o validación regional.
addresses.regionProvincia, estado o región.Útil para impuestos, logística o reglas locales.
addresses.countryPaís en formato legible o código según contrato final.Útil para cobertura, cumplimiento y facturación.
addresses.postal_codeCódigo postal.Útil para envío, impuestos o validación territorial.
addresses.is_primaryIndica si es la dirección principal.Pedilo si necesitás elegir una dirección por defecto.

Respuesta esperada

{
  "data": {
    "person_id": "per_7Q9M2K4R",
    "person_kyd": "BOB.CARTER",
    "fields": {
      "addresses": [
        {
          "type": "shipping",
          "city": "Buenos Aires",
          "region": "Ciudad Autónoma de Buenos Aires",
          "country": "AR",
          "postal_code": "C1000"
        }
      ]
    },
    "grant": {
      "status": "active",
      "scopes": ["person.addresses:read"]
    }
  }
}

Atributos de la respuesta

AtributoQué significaCómo usarlo
fields.addressesLista de direcciones autorizadas y devueltas.Puede venir vacía si no hay direcciones autorizadas o registradas para el filtro/campos pedidos.
typeUso de la dirección.No asumas que siempre existe una dirección de cada tipo.
city / region / countryUbicación general.Útil para validación, cobertura y reglas regionales.
postal_codeCódigo postal.Puede estar ausente si no fue pedido, no existe o no fue autorizado.
grant.scopesScopes que respaldan la lectura.Para direcciones de persona debe existir permiso de lectura de direcciones.

Variante por person_id

Si Acme ya guardó el person_id, puede consultar direcciones sin volver a enviar person_kyd.

{
  "person_id": "per_7Q9M2K4R",
  "service_name": "acme-shipping",
  "fields": ["addresses.city", "addresses.country"]
}

Errores comunes

ErrorQué significaQué hacer
grant_requiredAcme no tiene autorización activa para leer direcciones de Bob.Pedí consentimiento o ajustá el flujo para no requerir dirección.
field_not_allowedAlgún campo addresses.* no está cubierto por scopes/grant.Quitá el campo o solicitá el permiso correcto.
address_not_availableNo hay dirección registrada/autorizada para los campos pedidos.Mostrá una alternativa en tu flujo; no inventes dirección.
person_not_foundEl 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.

Request

QUERY https://dev.api.kydhub.com/api/v1/companies/query
X-API-KEY: $KYDHUB_API_KEY
Content-Type: application/json

{
  "company_kyd": "ACME.SUPPLIER",
  "service_name": "acme-risk",
  "fields": ["identity", "profile", "locations"],
  "response_profile": "standard",
  "format": { "locale": "en-US" }
}

Atributos del request

AtributoObligatorioSignificadoRegla
X-API-KEYYesServer-only API key for the requesting company.Identifies the caller company and applies audit/rate limits.
company_kydone of twoKnown KYD handle of the target company.Example: ACME.SUPPLIER.
company_identifierone of twoKnown company identifier accepted by the backend.Use it when your integration stores the canonical identifier returned by KydHub.
service_nameYesInternal service slug making the query.Must match ^[a-z0-9]+(?:-[a-z0-9]+)*$, e.g. acme-risk.
fieldsOptionalRequested company field groups.Allowed groups: identity, profile, locations. Defaults to identity.
response_profileOptionalOverall response profile.Current examples use standard.
formatOptionalPresentation options.Currently used for locale-sensitive subqueries such as locations.

Response

{
  "status": "success",
  "company_kyd": "ACME.SUPPLIER",
  "company_id": "comp_00000000-0000-4000-8000-000000000042",
  "service_name": "acme-risk",
  "response_profile_used": "standard",
  "fields": {
    "identity": {
      "company_kyd": "ACME.SUPPLIER",
      "company_id": "comp_00000000-0000-4000-8000-000000000042",
      "legal_name": "Acme Supplier LLC",
      "trade_name": "Acme Supplier",
      "country_code": "US",
      "profile_status": "complete",
      "is_active": true
    },
    "profile": {
      "website": "https://supplier.example",
      "logo_url": "https://cdn.example/supplier.svg",
      "activity_id": "activity-1"
    },
    "locations": [
      {
        "id": "loc-1",
        "name": "Headquarters",
        "type_name": "Office",
        "is_primary": true,
        "country_code": "US",
        "country_name": "United States",
        "postal_code": "33131",
        "address_detail": "1200 Brickell Ave",
        "reference": null,
        "latitude": 25.7617,
        "longitude": -80.1918
      }
    ]
  }
}

Atributos del response

AtributoSignificadoCómo usarlo
statusOperation result.success means the requested authorized groups were returned.
company_kydKnown public company KYD.Use it as the readable identifier for the company.
company_idPublic company ID for the company.Store it only as a public identifier; do not infer internal database IDs.
service_nameService slug received in the request.Useful for audit and debugging.
fields.identityAuthorized identity fields.Requires company.identity:read.
fields.profileAuthorized profile fields.Requires company.profile:read.
fields.locationsAuthorized 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.

Petición por company_kyd

QUERY https://dev.api.kydhub.com/api/v1/companies/query
X-API-KEY: $KYDHUB_API_KEY
Content-Type: application/json

{
  "company_kyd": "ACME.SUPPLIER",
  "service_name": "acme-supplier-review",
  "fields": [
    "locations.type",
    "locations.name",
    "locations.city",
    "locations.region",
    "locations.country"
  ]
}

Atributos de la petición

AtributoObligatorioQué significaRegla
company_kydUno de dosKYD público de la empresa consultada.Usalo cuando conocés el identificador KYD empresarial.
company_idUno de dosID público opaco de la empresa, como comp_00000000-0000-4000-8000-000000000042.Usalo si KydHub ya lo devolvió antes.
service_nameServicio que consulta las ubicaciones.Ejemplo: acme-supplier-review.
fieldsCampos de ubicación/dirección empresarial solicitados.Pedí sólo lo necesario para tu flujo B2B.

Campos de ubicación empresarial habituales

CampoQué devuelveCuándo pedirlo
locations.typeTipo de ubicación, por ejemplo headquarters, branch, billing o operations.Cuando necesitás distinguir casa matriz, sucursal u operación.
locations.nameNombre legible de la ubicación.Útil para mostrarla en UI o reportes.
locations.line1Línea principal de dirección empresarial.Sólo si necesitás dirección completa.
locations.line2Complemento o referencia.Opcional; pedilo sólo si tu operación lo usa.
locations.cityCiudad o localidad.Cobertura, logística o validación regional.
locations.regionProvincia, estado o región.Reglas fiscales, legales o logísticas.
locations.countryPaís.Cobertura, compliance o facturación internacional.
locations.postal_codeCódigo postal.Facturación, impuestos o envío físico.
locations.is_primaryIndica si es la ubicación principal.Para elegir ubicación por defecto.

Respuesta esperada

{
  "data": {
    "company_id": "comp_00000000-0000-4000-8000-000000000042",
    "company_kyd": "ACME.SUPPLIER",
    "fields": {
      "locations": [
        {
          "type": "headquarters",
          "name": "Main office",
          "city": "Miami",
          "region": "Florida",
          "country": "US",
          "is_primary": true
        }
      ]
    },
    "scopes": ["company.locations:read"]
  }
}

Atributos de la respuesta

AtributoQué significaCómo usarlo
fields.locationsLista de ubicaciones o direcciones empresariales autorizadas.Puede venir vacía si no hay ubicaciones disponibles/autorizadas.
typeUso o categoría de la ubicación.No asumas que todas las empresas tienen los mismos tipos.
nameNombre legible de la ubicación.Usalo para UI/reportes, no como ID único.
city / region / countryUbicación geográfica general.Útil para reglas regionales y validación de cobertura.
is_primaryMarca ubicación principal.Puede faltar si no fue solicitado o no está definido.
scopesScopes que respaldan la lectura.Para ubicaciones debe existir permiso de lectura de ubicaciones empresariales.

Variante por company_id

{
  "company_id": "comp_00000000-0000-4000-8000-000000000042",
  "service_name": "acme-supplier-review",
  "fields": ["locations.city", "locations.country"]
}

Errores comunes

ErrorQué significaQué hacer
company_not_foundNo existe empresa con ese company_kyd o company_id.Verificá el identificador por un canal autorizado.
company_locations_scope_requiredLa 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_availableNo hay ubicación disponible/autorizada para los campos pedidos.Mostrá una alternativa o pedí menos campos.
field_not_allowedAlgú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ónRecomendaciónPor qué
Acme ya tiene login propioPodés saltar OAuth de KydHub.Usá Data API con API key desde backend para consultar datos autorizados.
Acme quiere Login con KWIDUsá OAuth 2.0 + OIDC.KydHub autentica al usuario y devuelve tokens/claims verificables.
Aplicación web con backendUsá Authorization Code + PKCE y cliente confidencial si aplica.El backend puede guardar secretos de forma segura.
Aplicación móvil o escritorioUsá 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_idEl ID de la app de Acme en KydHub.
redirect_uriA dónde vuelve el usuario. Debe coincidir exacto con el registrado.
response_typeSiempre code.
scopeDatos que pedís, separados por espacio.
stateValor random anti-CSRF; lo validás al volver.
code_challengePKCE: el hash de tu code_verifier (método S256).
nonceOpcionalRecomendado: lo validás en el id_token para evitar replays.
login_hintOpcionalPre-llená el KWID (ej. BOB.CARTER).
promptOpcionallogin 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.

POST https://dev.auth.kydhub.com/oauth/login/start
Content-Type: application/json

{
  "client_id": "kh_client_…",
  "redirect_uri": "https://app.acme.example/callback",
  "scope": "openid kwid email profile company:read",
  "state": "RANDOM",
  "code_challenge": "…",
  "code_challenge_method": "S256",
  "verification_identifier": "BOB.CARTER"
}
Campo¿Obligatorio?Qué es
verification_identifierEl KWID/KYDid. Acá no va login_hint.
client_idEl ID de tu app.
redirect_uriEl mismo del paso 1, exacto.
scopeString con espacios, no array.
stateValor anti-CSRF del paso 1.
code_challengePKCE del paso 1.
code_challenge_methodS256.
nonceOpcionalRecomendado; validalo en el id_token.

La respuesta viene envuelta en data:

{
  "data": {
    "status": "pending_verification",
    "login_attempt_id": "login_attempt_…",
    "expires_at": "2026-06-19T15:30:00Z",  // TTL 15 min
    "challenge_prefix": "abc12345"     // solo diagnóstico
  }
}
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.

POST https://dev.auth.kydhub.com/oauth/token
Content-Type: application/json

{
  "grant_type": "authorization_code",
  "client_id": "kh_client_…",
  "client_secret": "CLIENT_SECRET_DEL_BACKEND",
  "code": "CODE_DEL_CALLBACK",
  "redirect_uri": "https://app.acme.example/callback",
  "code_verifier": "EL_VERIFIER_ORIGINAL"
}
Campo¿Obligatorio?Qué es
grant_typeSiempre authorization_code.
client_idEl ID de tu app.
client_secretSecreto del backend. Nunca en el cliente.
codeEl código que llegó al callback (un solo uso).
redirect_uriEl mismo del paso 1.
code_verifierEl PKCE original (el que generó el code_challenge).

Respuesta (objeto OAuth crudo, sin envoltorio data):

{
  "access_token": "…",
  "id_token": "…",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "openid kwid email profile company:read"
}
Hoy /oauth/token espera JSON (no form-urlencoded). Si tu librería solo manda form, agregá un adapter o vas a recibir un 422.

4 · Validar el token

Antes de confiar en el id_token, verificá su firma con el JWKS y chequeá los claims. Leé el jwks_uri desde discovery — no lo hardcodees.

ChequeoQué validar
FirmaVerificá con las llaves de jwks_uri (de discovery).
issDebe ser https://dev.kydhub.com.
audDebe ser tu client_id.
expNo expirado.
nonceIgual al que mandaste (si lo usaste).
Discovery y JWKS vienen envueltos en data: extraé data antes de pasarlos a una librería OIDC estándar.

GETUserInfo

Para qué sirve: traer los datos del usuario logueado. Llamás con el access_token como Bearer.

GET /userinfo
Authorization: Bearer ACCESS_TOKEN

{
  "sub": "person_01JDEVEXAMPLE",
  "kwid": "BOB.CARTER",
  "email": "bob.carter@example.test",
  "email_verified": true,
  "name": "Bob Carter",
  "given_name": "Bob",
  "family_name": "Carter",
  "picture": null
}
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:

ScopeClaims que devuelve
openidsub, iss, aud, exp, iat, auth_time (y nonce si lo mandaste).
kwidkwid.
emailemail, email_verified.
profilename, 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

EndpointCapacidadIdentificadorAutorización
QUERY /api/v1/persons/queryConsultar datos autorizados de persona.person_kyd o person_id.X-API-KEY, service_name, scopes y grant/consentimiento activo.
QUERY /api/v1/companies/queryConsultar 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/queryConsultar 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/queryConsultar ubicaciones autorizadas de empresa.company_kyd conocido o identificador de empresa soportado.X-API-KEY, company.locations:read y base válida de acceso.

Request base para query person

QUERY https://dev.api.kydhub.com/api/v1/persons/query
X-API-KEY: $KYDHUB_API_KEY
Content-Type: application/json

{
  "person_kyd": "BOB.CARTER",
  "service_name": "acme-checkout",
  "fields": ["person_id", "person_kyd", "name", "email"]
}

Requests base para query company

GET https://dev.api.kydhub.com/api/v1/companies/ACME.SUPPLIER
X-API-KEY: $KYDHUB_API_KEY

GET https://dev.api.kydhub.com/api/v1/companies/ACME.SUPPLIER/profile
X-API-KEY: $KYDHUB_API_KEY

GET https://dev.api.kydhub.com/api/v1/companies/ACME.SUPPLIER/locations?lang=es
X-API-KEY: $KYDHUB_API_KEY

Reglas de autorización

ReglaDetalle
Empresa solicitanteKydHub deriva la empresa solicitante desde la X-API-KEY server-only. No confíes en identificadores del body como identidad del solicitante.
ScopesLos scopes describen qué pide la integración. Los planes limitan capacidad; scopes más grants/consentimiento deciden qué datos se devuelven.
Grants y consentimientoLos datos de persona y datos protegidos de empresa requieren grant activo, consentimiento, relación autorizada u otra base explícita de acceso.
service_nameRequerido para query person. Usá un slug ASCII en minúsculas que cumpla ^[a-z0-9]+(?:-[a-z0-9]+)*$, por ejemplo acme-checkout.
Sin directorio abiertoQuery company es para empresas conocidas y autorizadas. No es búsqueda abierta ni browsing de empresas.
IDs públicosUsá per_... y comp_00000000-0000-4000-8000-000000000042 en contratos client-facing; nunca expongas UUIDs internos.
ErroresSi 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

PasoQué ocurreResponsable
1Acme registra una URL receptora en el portal de KydHub.Acme
2KydHub genera o muestra el secreto de firma del webhook.KydHub
3Cuando ocurre un evento, KydHub envía un POST al backend de Acme.KydHub
4Acme valida la firma HMAC antes de procesar el evento.Acme
5Acme guarda el event_id para evitar procesar duplicados.Acme

Evento recibido por Acme

POST https://app.acme.example/kydhub/webhook
X-KydHub-Event-Id: evt_01HVEXAMPLE
X-KydHub-Timestamp: 1760000000
X-KydHub-Signature-256: sha256=HEX_HMAC
Content-Type: application/json

{
  "id": "evt_01HVEXAMPLE",
  "type": "grant.approved",
  "created_at": "2026-06-28T12:00:00Z",
  "data": {
    "person_kyd": "BOB.CARTER",
    "company_id": "comp_00000000-0000-4000-8000-000000000042",
    "scopes": ["person.identity:read", "person.addresses:read"]
  }
}

Headers de seguridad

HeaderQué significaQué debe hacer Acme
X-KydHub-Event-IdID único del evento.Guardalo antes de procesar para que los reintentos sean idempotentes.
X-KydHub-TimestampMomento en que KydHub firmó/envió el evento.Rechazá timestamps demasiado viejos para reducir replays.
X-KydHub-Signature-256Firma HMAC-SHA256 del body crudo.Recalculá la firma con el secreto del webhook y compará timing-safe.
Content-TypeFormato del body.Esperá application/json.

Verificar firma en Node.js

import crypto from 'node:crypto';

function verifyKydHubWebhook(rawBody, signatureHeader, webhookSecret) {
  const expected = 'sha256=' + crypto
    .createHmac('sha256', webhookSecret)
    .update(rawBody)
    .digest('hex');

  return crypto.timingSafeEqual(
    Buffer.from(expected),
    Buffer.from(signatureHeader)
  );
}

Eventos típicos

EventoCuándo ocurreQué debería hacer Acme
grant.approvedUna persona aprobó que Acme lea ciertos datos.Actualizar estado interno y habilitar consulta Data API.
grant.rejectedUna persona rechazó la solicitud.Mostrar alternativa o pedir menos datos.
grant.revokedUna autorización fue revocada.Dejar de usar datos que dependan de ese grant.
webhook.delivery.failedKydHub no pudo entregar un evento tras intentos.Revisar disponibilidad del endpoint receptor.

Reintentos, idempotencia y límites

TemaReglaRecomendación
Respuesta exitosaRespondé 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.
ReintentosKydHub puede reintentar entregas fallidas.Procesá por event_id para evitar duplicados.
Company Free1 webhook activo y 1000 intentos de entrega por mes.Los reintentos cuentan contra el límite mensual.
SeguridadEl 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

CapaQué validaEjemplo
API keyQué empresa está llamando y si la key está activa.Acme llama con X-API-KEY.
Plan/límitesCuántas credenciales, requests o entregas puede usar la empresa.Company Free permite 2 API keys activas.
ScopesQué familias de datos puede leer una credencial.person.addresses:read.
GrantQué persona/empresa autorizó la lectura y para qué campos.Bob Carter autorizó lectura de identidad y direcciones.
FieldsQué 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.

AppScopes normalmente solicitadosPor qué
qbtChatperson.identity:read, person.name:read, person.email:read, person.profile.avatar:readLogin/perfil visible; no necesita dirección.
Mercado Libreperson.identity:read, person.name:read, person.identity.document:read, person.addresses.primary:readVerificación de identidad y envío después de aprobación explícita del usuario.

Scopes actuales documentados

ScopePermite leerUsado en
person.identity:readIdentificadores y nombre básico de persona.Consultar persona.
person.profile:readPerfil básico autorizado de persona.Consultar persona.
person.addresses:readDirecciones registradas/autorizadas de persona.Direcciones de persona.
company.identity:readIdentidad básica de empresa.Consultar empresa.
company.profile:readPerfil autorizado de empresa.Consultar empresa.
company.locations:readUbicaciones/direcciones registradas de empresa.Direcciones de empresa.
webhooks.events:readEventos webhook si se exponen diagnósticos.Diagnóstico/operación.
usage:readUso y consumo de API si el contrato lo habilita.Diagnóstico/operación.
audit:readEventos de auditoría permitidos.Diagnóstico/operación.

Company Free limits

ÁreaLímiteNotas
Personas por empresa2 total1 owner/founder y 1 collaborator.
API keys2 activasPueden no expirar; expiración opcional.
API rate limit60 requests/minAplicado por empresa/API key según contrato operativo.
API daily limit2.000 requests/díaDiseñado para pilotos e integraciones iniciales.
Webhooks1 activo1000 intentos de entrega/mes; los retries cuentan.
OAuth / Apps1 connected app, 1 OAuth clientHasta 3 redirect URIs.
Audit logs7 díasRetención básica.
SoporteBasic / best-effortSin SLA contractual.

Operaciones permitidas y prohibidas

TipoEstadoExplicación
Leer datos autorizados de personaPermitidoCon API key, scope de catálogo, grant/consentimiento/base válida activa y fields explícitos.
Leer direcciones autorizadas de personaPermitidoCon permiso de direcciones.
Leer datos autorizados de empresaPermitidoCon company_kyd o company_id conocido.
Leer ubicaciones autorizadas de empresaPermitidoCon company.locations:read.
Crear/modificar personas por API públicaProhibidoLa persona modifica sus datos dentro de KydHub.
Crear/modificar empresas por API públicaProhibidoSe administra desde el portal.
Administrar API keys/OAuth/webhooks por API públicaProhibidoPor ahora se hace desde el portal.
Buscar empresas sin identificadorProhibidoKydHub 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"]
}
AtributoQué significaCómo usarlo
errorCódigo estable del error.Usalo para lógica de UI/backend.
messageExplicación legible.Mostrala sólo si no expone datos internos; podés mapearla a copy propio.
request_idID de correlación.Incluilo al pedir soporte o revisar logs.
fieldsCampos afectados, cuando aplica.Útil para remover campos o pedir autorización correcta.

API keys y autenticación

ErrorQué significaCómo resolverlo
missing_api_keyNo llegó el header X-API-KEY.Enviá la API key desde el backend de Acme. No la envíes desde browser.
invalid_api_keyLa key no existe, fue revocada, expiró o está mal copiada.Creá o rotá una key desde Company → API Access.
api_key_limit_reachedLa empresa ya tiene el máximo de API keys activas.En Company Free, revocá una key activa antes de crear otra.
rate_limit_exceededSe superó el límite de requests por minuto.Reducí frecuencia, agregá backoff y revisá límites del plan.
daily_limit_exceededSe superó el límite diario.Esperá reinicio de ventana o consultá upgrade/contrato.

Identificadores y recursos

ErrorQué significaCómo resolverlo
person_not_foundNo existe persona para ese person_kyd o person_id.Verificá el identificador. No intentes adivinar identidades.
company_not_foundNo existe empresa para ese company_kyd o company_id.Confirmá el identificador por canal autorizado; KydHub no es directorio abierto.
invalid_identifierEl identificador tiene formato inválido.Usá BOB.CARTER, per_..., company_kyd o comp_00000000-0000-4000-8000-000000000042 según corresponda.
address_not_availableNo hay dirección de persona disponible/autorizada.Pedí menos campos o mostrale al usuario una alternativa.
location_not_availableNo hay ubicación empresarial disponible/autorizada.Continuá sin ubicación o pedí un campo menos sensible.

Scopes, grants y fields

ErrorQué significaCómo resolverlo
grant_requiredNo hay autorización activa para leer esos datos.Iniciá el flujo de autorización o pedí campos que no requieran ese grant.
grant_revokedLa autorización existía pero fue revocada.Dejá de usar esos datos y solicitá nueva autorización si corresponde.
field_not_allowedUno o más campos no están permitidos por scope/grant.Quitá campos, pedí menos datos o solicitá permisos adecuados.
scope_requiredLa 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_requiredFalta scope de lectura de empresa.Usá scopes como company.identity:read o company.profile:read.
company_locations_scope_requiredFalta permiso para ubicaciones de empresa.Revisá si la key tiene company.locations:read.

OAuth / Login con KWID

ErrorQué significaCómo resolverlo
login_requiredEl usuario no tiene sesión activa.Mostrá el flujo de verificación o redirigí a KydHub.
verification_requiredDebe completar verificación por email/magic link.No lo trates como fallo fatal; mostrale “Revisá tu email”.
invalid_redirect_uriLa URL callback no coincide exactamente con la registrada.Registrá https://app.acme.example/callback o la URL real exacta.
invalid_clientclient_id o secreto incorrecto.Revisá el OAuth client en el portal. No pongas secrets en apps públicas.
invalid_grantEl code expiró, ya fue usado o no corresponde al verifier.Reiniciá login y validá PKCE/state.
invalid_tokenToken inválido, expirado o con firma incorrecta.Validá issuer, audience, expiración y JWKS.

Webhooks

ErrorQué significaCómo resolverlo
webhook_signature_invalidLa firma HMAC no coincide.Usá el raw body exacto y el secreto correcto; compará timing-safe.
webhook_timestamp_expiredEl timestamp es demasiado viejo.Rechazá el evento y revisá reloj/sincronización.
webhook_duplicate_eventEl event_id ya fue procesado.No lo reproceses; devolvé 2xx si ya quedó persistido.
webhook_delivery_failedKydHub no pudo entregar el evento.Revisá disponibilidad pública, TLS y respuesta 2xx del endpoint.
webhook_limit_reachedSe 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

ErrorQué significaCómo resolverlo
pq_encryption_not_enabledLa capa no está habilitada para la empresa.Usá Data API normal o pedí habilitación contractual.
unknown_key_idEl kid no existe o fue rotado.Registrá/obtené la clave pública vigente.
decrypt_failedNo se pudo descifrar o falló AEAD.No proceses contenido; reintentá con clave válida.
unsupported_algorithmLa 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

ElementoValorNota
Ambiente sandbox/devhttps://dev.api.kydhub.com/api/v1Usado para pruebas y documentación actual.
Auth Data APIX-API-KEYSólo backend/secret manager. Nunca browser.
Empresa ejemploAcmeEmpresa integradora ficticia.
Persona ejemploBob Carter / BOB.CARTERPersona ficticia para ejemplos.
Empresa consultada ejemploACME.SUPPLIERKYD empresarial ficticio.
Modelo de APISólo lecturaNo crea, modifica ni elimina datos por API pública.

Matriz de capacidades actuales

CapacidadEndpoint didácticoIdentificadoresScopes típicos
Consultar personaQUERY /api/v1/persons/queryperson_kyd o person_idperson.identity:read, person.profile:read
Consultar direcciones de personaQUERY /api/v1/persons/queryperson_kyd o person_idperson.addresses:read
Consultar identidad de empresaQUERY /api/v1/companies/querycompany_kyd conocido o identificador de empresa soportado.company.identity:read
Consultar ubicaciones de empresaQUERY /api/v1/companies/querycompany_kyd conocido o identificador de empresa soportado.company.locations:read
Login con KWIDGET /oauth/authorizeclient_id, redirect_uriopenid, kwid, email, profile
WebhooksPOST https://app.acme.example/kydhub/webhookevent_idFirma HMAC + eventos contratados.

JSON para agentes

{
  "product": "KydHub",
  "environment": "sandbox",
  "base_url": "https://dev.api.kydhub.com/api/v1",
  "auth": {
    "data_api": {
      "type": "api_key",
      "header": "X-API-KEY",
      "storage": "backend_or_secret_manager_only"
    },
    "oauth_oidc": {
      "optional": true,
      "issuer": "https://dev.kydhub.com",
      "flow": "authorization_code_pkce"
    }
  },
  "read_only_public_api": true,
  "examples": {
    "integrator_company": "Acme",
    "person_kyd": "BOB.CARTER",
    "company_kyd": "ACME.SUPPLIER",
    "person_id": "per_7Q9M2K4R",
    "company_id": "comp_00000000-0000-4000-8000-000000000042"
  }
}

Operaciones permitidas

OperaciónPermitidaCondición
Leer campos autorizados de personaAPI key válida + scope de catálogo + grant/consentimiento/base válida + fields explícitos.
Leer direcciones autorizadas de personaperson.addresses:read y autorización activa.
Leer campos autorizados de empresacompany_kyd o company_id conocido.
Leer ubicaciones autorizadas de empresacompany.locations:read.
Usar Login con KWID/OIDCOpcionalSólo si Acme decide delegar login/verificación.
Recibir webhooks firmadosOpcionalWebhook registrado en portal + secreto HMAC.

Operaciones prohibidas para agentes

OperaciónEstadoRegla
Modificar datos de personas por API públicaNoLa persona administra sus datos dentro de KydHub.
Modificar empresas por API públicaNoLa empresa se administra desde el portal.
Crear API keys por API públicaNoLas API keys se crean desde el portal.
Crear OAuth clients por API públicaNoLos OAuth clients se administran desde el portal.
Buscar empresas sin identificadorNoKydHub no es directorio abierto.
Exponer secrets en código o logsNuncaUsar variables de entorno o secret manager.

Checklist para implementar

#ValidaciónResultado esperado
1Crear API key en portal.Secret guardado en backend/secret manager.
2Hacer request mínimo de persona.Respuesta contiene sólo campos pedidos/autorizados.
3Probar falta de scope/campo no permitido.Error seguro tipo field_not_allowed.
4Si hay OAuth, validar state, nonce y JWKS.Login seguro y tokens verificados.
5Si hay webhooks, validar HMAC e idempotencia.Eventos firmados y sin procesamiento duplicado.
6Documentar 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ónRecomendaciónMotivo
Integración estándar de Data APINo es obligatorio.TLS, API key, scopes y grants ya son la base de seguridad.
Payloads con PII sensiblePuede activarse si el contrato lo habilita.Agrega confidencialidad del body además del canal TLS.
Webhooks con datos sensiblesPuede usarse junto con firma HMAC.La firma verifica integridad/origen; el cifrado protege contenido.
Cliente sin soporte criptográficoNo lo actives todavía.Primero integrá Data API normal y luego agregá esta capa.

Qué no reemplaza

ControlSigue siendo obligatorioPor qué
TLS/HTTPSProtege el canal de transporte.
API keyIdentifica a la empresa que llama.
OAuth/OIDCSí, si usás Login con KWIDAutentica usuarios y emite claims/tokens.
Scopes y grantsDeciden qué datos pueden leerse.
Firma de webhooksVerifica origen e integridad del evento.
AuditoríaPermite rastrear quién pidió qué y cuándo.

Cómo funciona a alto nivel

PasoQué pasaResultado
1 · Clave públicaEl receptor publica o registra una clave pública de cifrado.El emisor sabe con qué clave proteger el payload.
2 · KEM post-cuánticoEl emisor encapsula un secreto usando ML-KEM/Kyber.Se obtiene un secreto compartido resistente al modelo post-cuántico.
3 · ECDH clásicoSe genera además un secreto X25519 efímero.Defensa híbrida clásica + post-cuántica.
4 · DerivaciónAmbos secretos entran a HKDF.Se deriva una clave simétrica para cifrar.
5 · AEADEl payload se cifra con AES-256-GCM u otro AEAD aprobado.Confidencialidad e integridad del cuerpo cifrado.

Ejemplo de envoltorio cifrado

{
  "protected_payload": {
    "alg": "KydHub-HybridPQ-MLKEM768-X25519-HKDF-AES256GCM",
    "kid": "kh_pq_key_2026_06",
    "kem_ciphertext": "BASE64URL_ML_KEM_CT",
    "ecdh_public_key": "BASE64URL_X25519_PUB",
    "nonce": "BASE64URL_96BIT",
    "ciphertext": "BASE64URL_AEAD_CT",
    "aad": "method=QUERY;path=/api/v1/persons/query;event=grant.approved"
  }
}

Atributos del envoltorio

AtributoQué significaRegla
algAlgoritmo/paquete criptográfico usado.Debe estar acordado por KydHub y Acme.
kidID de la clave pública usada.Permite rotar claves sin romper integraciones.
kem_ciphertextCiphertext del KEM post-cuántico.Lo usa el receptor para recuperar el secreto compartido.
ecdh_public_keyClave pública efímera X25519 del emisor.Participa en la derivación híbrida.
nonceNonce usado por el cifrado AEAD.No debe repetirse para la misma clave.
ciphertextPayload cifrado.Contiene los datos reales protegidos.
aadDatos autenticados no cifrados.Vincula el payload con método, path, evento o contexto.

Errores y fallback

ErrorQué significaQué hacer
pq_encryption_not_enabledLa empresa no tiene habilitada esta capa.Usá Data API normal o solicitá habilitación.
unknown_key_idEl kid no existe o fue rotado.Obtené/registrá la clave pública actual.
decrypt_failedEl 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_algorithmEl 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.

Markdown

Versión Markdown

Descargar .md
Cargando Markdown formateado…
Cargando Markdown…

Referencia

Referencia de API

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.