Fuentes

La API resuelve identidad combinando varias fuentes. Cada fuente aporta una dimensión distinta del sujeto y llega siempre como un payload versionado con su schemaRef: el conocimiento propio de esa fuente, sin deformar.

Hay dos maneras de consumirlas, y las dos devuelven exactamente los mismos payloads:

	Person Search	Consulta por fuente
Pregunta	¿Quién es este sujeto?	¿Qué dice esta fuente?
Fuentes	Las que decide el modelo	La que vos elegís
Endpoint	POST /api/v1/person-search/search	POST /api/v1/sources/{source}/query
Resultado	Sujetos resueltos con todas sus dimensiones	Sujetos con una dimensión: la de esa fuente
Precio	1 consulta del producto	Tarifa de la fuente (más barata)

Usá Person Search cuando querés resolver identidad; usá la consulta por fuente cuando ya sabés a qué registro querés preguntarle y no querés pagar (ni esperar) por lo demás.

Catálogo

Cada fuente tiene su página con lo que trae, sus claves y su payload:

Fuente	Slug	Modo	Claves	Payload	Scope
IGJ · Registro societario	igj	LOCAL	cuit, name	igj.company.v1	provider:igj
ARCA · Padrón fiscal	arca	LOCAL	cuit, name	arca.padron.v1	provider:arca
BCRA · Central de Deudores	bcra	LIVE	cuit (obligatorio)	bcra.credit.v1	provider:bcra
InformeLegal · Personas	informelegal	LIVE	cuit (obligatorio)	informelegal.persona.v1	provider:informelegal

Modo dice de dónde sale el dato:

• LOCAL — réplica propia versionada del registro. Respuesta rápida y estable; la frescura depende del último ciclo de ingesta.
• LIVE — consulta en vivo al organismo en el momento del request. Máxima frescura, mayor latencia y sujeta a la disponibilidad del origen (si el origen falla, la respuesta viene con partial: true).

Descubrir el catálogo desde la API

El mismo catálogo está disponible como endpoint, con un dato que la documentación no puede darte: si tu API Key puede usar cada fuente hoy.

curl https://tu-host/api/v1/sources \
  -H "Authorization: Bearer ilk_live_xxx"

{
  "sources": [
    {
      "source": "igj",
      "name": "IGJ · Registro societario",
      "description": "Sociedades inscriptas en la Inspección General de Justicia…",
      "mode": "LOCAL",
      "payloadSchemaRef": "igj.company.v1",
      "supportedKeys": ["cuit", "name"],
      "requiredKeys": [],
      "requiredScopes": ["provider:igj"],
      "authorized": true,
      "price": { "amount": 0.25, "currency": "USD" }
    }
  ]
}

Campo	Significado
source	Slug que va en la ruta de la consulta.
mode	LOCAL (réplica) o LIVE (consulta al origen).
payloadSchemaRef	Forma del data que vas a recibir.
supportedKeys	Claves que la fuente sabe resolver.
requiredKeys	Claves sin las cuales la consulta no se puede ejecutar (400).
requiredScopes	Scopes que tu key necesita, además de sources:read.
authorized	Si tu key puede consultarla hoy.
price	Precio comercial por consulta a esa fuente.

El catálogo es metadata: no factura ni consume cuota. Requiere el scope sources:read.

GETProbar el catálogo→

Consultar una fuente

curl -X POST https://tu-host/api/v1/sources/igj/query \
  -H "Authorization: Bearer ilk_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{ "keys": { "cuit": "30111111119" } }'

Campo	Req.	Descripción
keys	sí	Claves de búsqueda. Al menos una; deben estar entre las supportedKeys de la fuente.
entityType	no	Hint de clase (PERSON). Si se omite, el motor resuelve NATURAL_PERSON/LEGAL_ENTITY.

POSTProbar la consulta por fuente→

La respuesta usa el mismo envelope que Person Search, más el source consultado:

{
  "source": "igj",
  "queryId": "dq_01J0000000000000000000EXMP",
  "resolvedEntityType": "LEGAL_ENTITY",
  "subjects": [
    {
      "resolvedEntityType": "LEGAL_ENTITY",
      "identity": {
        "identifiers": [{ "type": "CUIT", "value": "30111111119", "country": "AR" }],
        "names": [{ "kind": "LEGAL_NAME", "value": "EJEMPLO S.A." }]
      },
      "score": 100,
      "payloads": [
        { "schemaRef": "igj.company.v1", "version": "1.0.0", "data": { } }
      ]
    }
  ],
  "partial": false,
  "cost": { "amount": 0.25, "currency": "USD" },
  "correlationId": "7f3e0c2a-4b1d-4e5f-9a8b-0c1d2e3f4a5b"
}

Cada sujeto trae exactamente un payload: el de la fuente consultada. Es el mismo objeto que aparecería, junto a otros, dentro de una búsqueda de Person Search.

Permisos, y por qué acá un 403 sí es un error

En Person Search, una fuente para la que no tenés permiso simplemente no aparece en el resultado: el resto de la búsqueda sigue siendo útil. Acá la fuente es la consulta, así que devolver un 200 vacío sería engañoso: sin el scope de la fuente la respuesta es 403.

Necesitás sources:read más el provider:<fuente> correspondiente (Autenticación y scopes).

Claves faltantes: 400, no "sin resultados"

Si la fuente exige una clave que no enviaste (BCRA exige cuit), la respuesta es 400 con el requisito explícito:

{
  "statusCode": 400,
  "message": "Ninguna fuente de descubrimiento del modelo puede ejecutarse con las claves provistas [NAME]. Requisitos mínimos por fuente: BCRA(CUIT)",
  "error": "Bad Request"
}

Es distinto de una búsqueda válida que no encontró nada, que devuelve 200 con subjects: []. La API no colapsa "no pude ejecutar" con "ejecuté y no hay".

Un payload abierto

Todas las fuentes devuelven payloads versionados por este contrato, con una excepción declarada: InformeLegal adjunta la respuesta cruda del proveedor. El envelope es el de siempre; lo que no está versionado por nosotros es el contenido de data.

Ver también: Payloads por dominio · Errores · Límites y facturación.