Apariencia
Referencia de la API v1
Esta referencia se genera a partir de la especificación OpenAPI, que es la fuente canónica del contrato. Recordá que la obligatoriedad de los campos de human/company es dinámico por organización: ver Contrato de campos.
API servidor-a-servidor para crear y avanzar legajos de apertura de cuenta
(personas humanas y jurídicas) sin pasar por la pantalla del operador.
El cliente HTTP es siempre un sistema controlado por su organización,
autenticado con un token de API. El contrato de campos de human/company
es dinámico por organización: el bulk POST valida en runtime contra la
configuración de Campos configurables. Ver la guía "Contrato de campos".
Servers
https://compliance.quantian.ar/apiBase URL única de la API pública.
Listar legajos
GET
/v1/accounts
Lista los legajos de su organización, paginados, ordenados por
created_at descendente. Ability requerida: accounts:read.
Authorizations
bearerAuth
Token de API en el header Authorization: Bearer
Type
HTTP (bearer)
Parameters
Query Parameters
per_page
Type
integer
Default
20Maximum
100page
Type
integer
Default
1Responses
Página de legajos.
application/json
{
}
Crear legajo (bulk create)
POST
/v1/accounts
Crea un legajo completo con todas sus
secciones anidadas en una sola llamada, dentro de una transacción: si
falla la validación, no se crea nada. Ability requerida: accounts:write.
El required-ness de los campos de human/company lo define la
configuración de Campos configurables de su organización y se valida en
runtime — un campo requerido faltante devuelve 422 con la clave en
dot-notation (ej. human.tax_id_number). Ver la guía "Contrato de campos".
Authorizations
bearerAuth
Token de API en el header Authorization: Bearer
Type
HTTP (bearer)
Request Body
application/json
{
}
Responses
Legajo creado.
application/json
{
}
Detalle de un legajo
GET
/v1/accounts/{account}
Detalle de un legajo. Ability requerida: accounts:read.
Authorizations
bearerAuth
Token de API en el header Authorization: Bearer
Type
HTTP (bearer)
Responses
El legajo.
application/json
{
}
Estado de completitud del legajo
GET
/v1/accounts/{account}/checklist
Mismo checklist que ve el operador en el backoffice: grupos de campos,
documentos requeridos, completos/faltantes. La forma sigue al servicio
interno de checklist y refleja Requerimientos Documentales + Campos
configurables de su organización. Ability requerida: accounts:read.
Authorizations
bearerAuth
Token de API en el header Authorization: Bearer
Type
HTTP (bearer)
Responses
El checklist.
application/json
{
}
Enviar legajo al circuito de firma/validación
POST
/v1/accounts/{account}/submit
Envía el legajo según la entrega de firma de su flujo (signature_mode:
email, api_link o none, heredado del flujo elegido al crear el
legajo). Ability requerida: accounts:write.
Pre-condiciones: el legajo en draft o in_progress; titular y
firmantes con email cargado.
Idempotencia: si el legajo ya está en pending_signature o más
avanzado, devuelve 200 con el estado actual sin re-disparar la firma.
Authorizations
bearerAuth
Token de API en el header Authorization: Bearer
Type
HTTP (bearer)
Request Body
application/json
{
}
Responses
Resultado del envío. signature.urls aparece sólo en modo api_link;
signature.status sólo en email. investor_profile_renewal es null
salvo que se hayan disparado renovaciones de perfil de inversor.
application/json
{
}
Listar documentos del legajo
GET
/v1/accounts/{account}/documents
Documentos subidos al legajo, paginados, ordenados por created_at desc. Ability requerida: accounts:read.
Authorizations
bearerAuth
Token de API en el header Authorization: Bearer
Type
HTTP (bearer)
Parameters
Query Parameters
per_page
Type
integer
Default
50Maximum
100page
Type
integer
Default
1Responses
Página de documentos.
application/json
{
}
Subir un documento
POST
/v1/accounts/{account}/documents
Sube un documento al legajo. Se valida el MIME declarado y los
magic-bytes del archivo. Ability requerida: accounts:write.
Authorizations
bearerAuth
Token de API en el header Authorization: Bearer
Type
HTTP (bearer)
Request Body
multipart/form-data
object
file
string
Required
Tipos: pdf, png, jpg, jpeg, gif, bmp, tiff. Máx 50 MB.
Format
"binary"target
string
Si no se pasa, se infiere por el tipo del legajo.
Valid values
"human""company"document_classification_id
string
Format
"uuid"description
string
Max Length
500expiration_date
string
Format
"date"Responses
El documento creado.
application/json
{
}
Borrar un documento
DELETE
/v1/accounts/{account}/documents/{document}
Borra el documento y su archivo del storage. Ability requerida: accounts:write.
Devuelve 404 si el documento no pertenece al legajo (no se distingue de
"no existe", para no filtrar la existencia de documentos en otros legajos).
Authorizations
bearerAuth
Token de API en el header Authorization: Bearer
Type
HTTP (bearer)
Responses
Borrado, sin cuerpo.
Emitir magic-link para el consumidor
POST
/v1/accounts/{account}/hosted-flow/link
Emite un magic-link para que el consumidor cierre el legajo en el portal de onboarding.
Ability requerida: accounts:write.
Pre-condiciones: el legajo creado por API (created_via = "api"); en
estado draft o in_progress; si ya tiene consumidor vinculado, el
email debe coincidir (case-insensitive).
Authorizations
bearerAuth
Token de API en el header Authorization: Bearer
Type
HTTP (bearer)
Request Body
application/json
{
}
Responses
El magic-link emitido.
application/json
{
}
Listar los flujos de apertura activos
GET
/v1/onboarding-flows
Flujos de apertura activos de su empresa. Usá el slug como valor de onboarding_flow al crear un legajo. Ability requerida: accounts:read.
Authorizations
bearerAuth
Token de API en el header Authorization: Bearer
Type
HTTP (bearer)
Responses
Flujos de apertura activos de su empresa.
application/json
{
}
Listar un catálogo global
GET
/v1/catalogs/{catalog}
Valores de un catálogo global de referencia. Ability requerida: accounts:read.
Authorizations
bearerAuth
Token de API en el header Authorization: Bearer
Type
HTTP (bearer)
Responses
Los valores del catálogo. La forma de cada item depende del catálogo:
countries → {id, name, iso2}; condicion_iva y condicion_ganancias
→ {id, name}; tipo_societario → {id, sigla, long_name}; cnv_entity_types
→ {id, key, label, legal_reference}.
application/json
{
}
Contrato del bulk POST como JSON Schema
GET
/v1/payload-schema/{accountType}
Devuelve el contrato de campos del bulk POST (POST /v1/accounts) de su
organización como JSON Schema Draft 2020-12, uno por tipo de cuenta
(ph o pj). Los campos que la organización exige para completar el
legajo se enumeran en x-quantian-required-for-completion (dentro de
human/company); el schema no usa required a nivel de entidad porque
el bulk POST acepta payloads parciales (los datos faltantes se completan
luego en el onboarding); los campos *_id referencian catálogos globales
vía la extensión x-quantian-catalog; las dependencias condicionales se
expresan con if/then y se anotan con x-quantian-depends-on.
La respuesta es el JSON Schema crudo (no envuelto en {data}), pensado para
enviarse directamente a un validador y chequear el payload localmente antes de
enviarlo. Ability requerida: accounts:read.
Authorizations
bearerAuth
Token de API en el header Authorization: Bearer
Type
HTTP (bearer)
Responses
El JSON Schema del payload para el tipo de cuenta.
application/json
{
}