Changelog

2026-09-20 — el registro frena a menores y países no operados; el logout mata el token

Cuatro correcciones en Auth salidas de la batería e2e. Dos cambian lo que responde el API:

• PUT /auth/users/{platform}/register rechaza a menores de 18: 400 con código auth-UNDERAGE y mensaje You must be at least 18 years old to register.. La app y platform ya lo frenaban en cliente; ahora el servidor es la frontera y el código es estable para mapearlo.
• El país de residencia tiene que ser uno operado: residenceCountryId fuera de los países con los que Tikin opera (hoy Colombia, id 42 en masterdata) responde 400 auth-COUNTRY_NOT_ALLOWED, el mismo código con el que el registro ya rechaza prefijos telefónicos. Antes cualquier id entraba y el error aparecía recién al abrir la cuenta, como un 500 del libro. birthCountryId no se restringe.

Las otras dos no cambian el contrato pero sí el comportamiento:

• PUT /auth/users/{platform}/change-pin valida el PIN actual antes de comparar el nuevo: con un PIN actual incorrecto la respuesta es siempre 401 auth-INVALID_PIN y consume intento (antes SAME_PIN_NOT_ALLOWED revelaba el PIN real sin gastar intentos).
• PUT /auth/users/{platform}/reset-pin con OTP válido levanta el bloqueo por intentos (TIME_BLOCK_PIN), y POST /auth/authenticator/{platform}/logout-session/{deviceId} deja el access token vigente inservible al instante, también cuando el dispositivo había iniciado sesión más de una vez. Un segundo login desde el mismo deviceId cierra el anterior.

2026-09-19 — el PIN es de 4 a 8 dígitos

El PIN de seguridad deja de ser de exactamente 4 dígitos: ahora son solo dígitos, mínimo 4 y máximo 8. Aplica al header Pin de las rutas que exigen PIN (retiros y POST /v1/payouts) y a los endpoints de Auth que lo crean, cambian, restablecen o validan. Nada se rompe: los PIN de 4 dígitos que ya existen siguen valiendo tal cual, y el pattern publicado pasa de ^\d{4}$ a ^\d{4,8}$. Un PIN con letras, con menos de 4 o con más de 8 dígitos responde 400 con el motivo en el message.

2026-09-11 — borde de producto en public-api

public-api absorbe las rutas instaladas del gateway: sesión, PIN, OTP, pertenencia de cuenta y canales internos se validan antes de consultar los servicios. El contrato v1 de tenant conserva sus scopes y Tikin-Version. Se mantienen las rutas de Auth, Accounts, identidad, recargas, comprobantes, lotes y notificaciones; multipart y webhooks conservan sus bytes y SSE conserva open/keepalive sin buffering.

GET /bff/v1/home ahora consulta los movimientos reales del libro: cada sección responde con data, error y ok y degrada por separado a los cinco segundos. No se presenta una lista vacía cuando falla el historial. Los saldos conservan COPM/2 y DUSD/6; las transferencias y bonos instalados mantienen PIN, cuenta, interruptor por entorno e Idempotency-Key, sin redondear importes.

Las funciones de proveedores retirados conservan sus listas vacías o estados explícitos. /compat/** permanece inaccesible, los endpoints privados de Auth siguen bloqueados salvo su allowlist administrativa y se rechazan rutas ambiguas y cabeceras de identidad duplicadas. El cambio de destino de los dominios se valida por entorno durante el despliegue; las aplicaciones conservan sus URLs.

2026-09-11 — comprobantes históricos en payment-rails

La consulta compatible /transaction-voucher/voucher/{id} conserva los IDs, nombres y transacciones originales, con acceso exclusivo del usuario que subió el comprobante. Los históricos tienen URL firmada de 900 segundos y contenido base64; si el objeto falta, la respuesta conserva sus datos y devuelve content: null. Los fallos de almacenamiento responden 503. Los nuevos comprobantes mantienen URL de 300 segundos. Estas consultas no crean órdenes ni mueven fondos.

2026-09-11 — scopes visibles, versión por fecha y ?expand=

Tres cosas que un tenant pedía poder saber antes de intentar (TIKIN-352). Ninguna rompe: la versión sigue siendo 2026-09-08.

• GET /v1/tenant dice qué puede tu token. Nuevo campo scopes (read, transfers, payouts, bonuses) y nuevo api_version (effective, requested, latest). Las rutas hacen cumplir el scope: una fuera de alcance responde 403 insufficient_scope con el message diciendo cuál faltó. Las credenciales existentes tienen los cuatro; una acotada se acuña como tal. Autenticación →
• Tikin-Version por fecha. Manda Tikin-Version: YYYY-MM-DD para anclar tu integración; toda respuesta de /v1 trae el header con la versión que rige. Sin header rige la más reciente. Versionado →
• ?expand=counterparty en el historial. GET /v1/accounts/{id}/movements?expand=counterparty trae alias, display_name y type de la contraparte en el mismo viaje. Lo que no se pueda resolver queda como {account_id}: un nombre que no se pudo verificar no se inventa. Un valor de expand fuera del catálogo es 400 invalid_field.

2026-09-11 — beneficiarios de lotes con alta reanudable

La validación de archivos consulta cuentas y billeteras por tenant y moneda. Los teléfonos nuevos se registran con IDs estables; las filas repetidas comparten beneficiario. Una cuenta sin billetera en la moneda pedida no crea otra cuenta. El alta permanece sin verificar y no infiere país a partir de moneda o teléfono.

Si falta completar una membresía o un paso de registro, la fila devuelve registration_pending y una nueva validación retoma la misma cuenta. Una caída de Accounts o identidad devuelve 503. El contrato instalado POST /payment-batch/{integration}/process-batch queda documentado con su formulario Excel: validar conserva las transacciones pendientes y no mueve fondos.

2026-09-11 — notificaciones con historial durable

El sucesor TypeScript conserva las rutas de dispositivos e historial del producto. Cerrar sesión elimina todas las filas duplicadas de un dispositivo; registrar un token nuevo vuelve a habilitarlo. El historial se conserva aunque FCM rechace un push, y marcar como leída una notificación exige el usuario y la cuenta correctos.

Los eventos responden 202 después de guardarse, con ID y estado. Admiten Idempotency-Key; una plantilla desconocida devuelve 422 y un cuerpo inválido 400. Los reintentos se aíslan por destinatario y los códigos OTP vencidos no se reenvían. La aceptación de un proveedor no confirma recepción en el teléfono. La generación y validación del OTP de login continúan en integration-auth; el envío de SMS pasa al sucesor y conserva Twilio. Un rechazo o una respuesta sin SID de Twilio devuelve error al flujo de login. Los fallos se reportan a GlitchTip y al canal de operaciones con reintentos persistentes; también se vigilan saldo, estado de cuenta, entrega y 24 horas sin SMS aceptados. El admin incorpora edición de plantillas con vista previa y registro de quién guardó cada cambio; exige acceso de plataforma.

2026-09-11 — límites y retiro de consultas antiguas de wallets

La pantalla de límites consulta el libro mediante public-api. El consumo mensual incluye reservas vigentes y los topes ausentes conservan su significado; AVISO no introduce restricciones efectivas. La renovación es una fecha calendario. Esta lectura sustituye el acumulado de la tabla antigua de transacciones. Los límites en USD usan seis decimales, como DUSD en el libro. Se corrige la escala inicial de ocho decimales de este adaptador, que reducía cien veces los importes mostrados en USD; no modificaba el monto contabilizado ni su control.

Las consultas de detalle y relación PSE de wallets responden 410 después de validar la sesión. Platform genera el comprobante desde el movimiento ya consultado y conserva los centavos; una comisión desconocida no se presenta como gratuita. El retorno de PSE informa que el método no está disponible y no acredita pagos por el estado de la URL. La app muestra «Retiro solicitado» cuando el retiro queda en cola. Las rutas de wallets sin contrato migrado explícito responden 410.

2026-09-11 — gráficos, exportaciones y divisas desde el libro

Los gráficos diarios y el XLSX de versiones instaladas leen todos los asientos contabilizados del bolsillo, incluidas las comisiones registradas en el libro. Los días son UTC y el gráfico contiene exactamente el mes solicitado. El XLSX incluye ambos días del rango, mantiene sus siete columnas y presenta las comisiones como filas separadas. Guarda los importes como texto decimal exacto para evitar el redondeo de Excel. Admite hasta 10.000 asientos y 3.660 días; un límite excedido o una fuente caída responde 503, sin entregar una exportación parcial.

Los alias de divisas conservan sus formas, fechas de vigencia e historia desde el catálogo del libro. Las tasas siguen siendo informativas.

2026-09-11 — retiros bancarios del producto en v1

POST /v1/payouts admite la sesión del producto con X-Product-Session: true, Tenant, Account y PIN. debit_amount es bruto en centavos COPM como texto; source_wallet y destination_id se validan dentro de la cuenta activa y verificada. La respuesta conserva amount neto y fee. La lectura por ID valida la misma sesión sin pedir PIN. El contrato B2B por defecto mantiene su monto neto y token de tenant.

recipient_country sólo contiene el país declarado por la persona; omitirlo no lo reemplaza por el país del banco. El alias de versiones instaladas conserva su forma y su UUID de operación. La app conserva la llave del intento después de un timeout y la cambia al iniciar otro pedido. Un retiro en cola aún espera ejecución.

2026-09-11 — historial compatible desde el libro

Los alias /wallet-service/transactions/{tenant}/account y /wallet-service/transactions/{tenant}/wallet/{walletId}, junto con los movimientos de versiones instaladas bajo /bloque-executor/api/v1/users/wallets, consultan el historial contable por la cuenta de la sesión. Conservan importes, etiquetas, comisiones y destinos bancarios históricos cuando existe evidencia. Un bolsillo ajeno responde 404.

Los campos total y total_pages conservan sus cotas de paginación. La búsqueda histórica por banco sigue acotada y no sustituye una exportación. Si una fuente falla se responde 503; no se presenta un vacío falso. Los saldos y metadatos de bolsillos se componen desde el libro y Accounts con credenciales internas.

2026-09-11 — catálogo de divisas en el libro

GET /v1/fx/rates?pair=USD/COP consulta el catálogo del libro. Conserva pair, rate como texto decimal, source y as_of, junto con la historia de tasas de la TRM. La fecha representa la vigencia publicada; si la fuente externa no responde se conserva la última tasa conocida con su fecha real. Las tasas siguen siendo informativas y no convierten saldos ni asientos.

2026-09-11 — cuentas del producto en Accounts

Las rutas /wallet-service/accounts/{tenant} conservan el alta, listado, destinatarios, identificación y direcciones del producto con su sesión de usuario. El listado mantiene is_auto_generated y su duplicado histórico autoGenerated. El servidor obtiene las membresías y el dueño desde la sesión.

Cambiar TikinTag conserva PIN, frecuencia de 30 días y cuarentena de 90 días; la consulta de disponibilidad y las sugerencias también respetan nombres reservados y cuarentena. El alta se reintenta con el mismo usuario y tag sin crear otra cuenta ni membresía. La baja lógica exige dueño y OTP, conserva historia e invalida las sesiones anteriores de los miembros.

El resultado de KYC llega por un canal interno autenticado. Su hecho de identidad se guarda separado de la capacidad operativa, que se declara en el libro después de evaluar AML/KYB. El antiguo intake público de verificación de wallets deja de estar disponible (410).

2026-09-11 — cotizaciones por cuenta y tarifas precisas

POST /v1/quotes acepta source_account y recipients. La cuenta selecciona su tarifa particular y el retiro gratis del mes; el monto y los destinatarios seleccionan sus tramos. fee_policy devuelve el porcentaje exacto en partes por millón y sus dos componentes: 114030 ppm conserva el 11,403 % completo.

GET /v1/accounts/{id}/limits expone límites y su modo de aplicación. GET /v1/accounts/{id}/fee-benefits informa la disponibilidad del retiro gratis mensual y expires_at, su vencimiento real en Colombia. Consultar no consume beneficios ni cupo; una cuenta ajena al token responde 404.

La app y el checkout conservan las consultas de tarifa, límite y beneficio por sus rutas anteriores. El CRUD anterior de tarifas deja de publicarse por el borde; las tarifas se administran en la consola. La migración conserva los mínimos vigentes, las excepciones de cuenta y los precios exactos en las fronteras de los tramos, sin activar topes mensuales nuevos.

2026-09-11 — recargas por transferencia con revisión bancaria

POST /v1/payins crea instrucciones bancarias propias, con una llave de idempotencia por cuenta. /v1/funding-banks conserva el catálogo del entorno. Estas rutas requieren sesión del producto Tikin y headers Tenant y Account, distintos del token B2B de tenant.

El comprobante se adjunta como archivo PDF, PNG, JPEG o WebP de hasta 5 MiB. Subirlo no acredita saldo: una revisión bancaria confirma importe, referencia y evidencia antes del asiento. Los estados son pendiente_comprobante, pendiente_revision, contabilizando, acreditada, rechazada y cancelada. En contabilizando se consulta la misma orden; no se crea otra para resolver un timeout. Solo acreditada con transferId confirma el abono. Los importes COPM son strings en centavos: amount es bruto, fee es comisión y el saldo recibido es su diferencia.

Los listados tienen filtros, página y total reales. Los enlaces de comprobantes nuevos vencen en 300 segundos y content.data del alias antiguo queda vacío, sin base64. Se conservan los aliases de transferencia, bancos, cancelación y voucher; important_notes sigue siendo una lista. El límite nuevo de archivo es 5 MiB; PSE y tarjeta responden 410. Los comprobantes históricos mantienen lectura autorizada.

2026-09-11 — agenda de contactos en Accounts

La agenda del producto Tikin está disponible en /v1/accounts/{account}/contacts y conserva los aliases /transfer-accounts/*, los IDs y los ceros iniciales de cuentas y documentos. Los catálogos de destinos son /v1/catalog/transfer-countries, /v1/catalog/banks y /v1/catalog/payment-wallets; bancos y billeteras reciben country_id. Estas rutas requieren la sesión del usuario y los headers Tenant y Account; son distintas del API de plataforma con token de tenant.

Cada operación verifica que el contacto pertenezca a la cuenta autenticada: un contacto ajeno responde 404. Agregar varios destinos procesa la lista completa y revierte toda la escritura si alguno es inválido. Crear/renombrar devuelve la identidad del contacto sin relaciones recursivas; las consultas mantienen sus listas y representan las vacías como null. Cuerpos de más de 64 KiB se rechazan con 413; los identificadores deben ser texto y cada lista admite hasta 100 destinos.

Inactivar o reactivar un contacto cambia todos sus destinos en la misma operación. Reactivar vuelve a activar también los destinos inactivados individualmente, como el contrato anterior.

2026-09-11 — catálogos públicos de Accounts

Las lecturas públicas de países, monedas, tipos de documento, redondeos y términos están disponibles en /v1/catalog/*. Los aliases /masterdata/v1/* mantienen sus IDs, formatos y textos completos para las integraciones existentes; no requieren credenciales. Los términos conservan los datos propios de cada entorno.

Si no existen términos del país ni respaldo de Colombia, ambos prefijos responden 404 con datamaster-TERMS_NOT_FOUND y details: null, igual que el contrato anterior. Los errores de parámetros mantienen details como objeto.

2026-09-11 — la verificación de empresas: cada persona clave, con su propio enlace

No cambia ningún contrato de api.tikin.is. Lo que cambia es que ahora está escrito por qué una empresa puede quedar «verificando» durante días: el trámite de Didit exige que cada persona clave que la empresa declara —representante legal, beneficiarios finales, accionistas— verifique su identidad una por una, con un enlace propio que le llega por correo, y la empresa queda retenida hasta que la última termine.

Ampliada la sección verificación de empresas: qué le tenés que decir al representante antes de empezar, qué estados tiene cada persona (sin invitar · invitada · verificándose · verificada · rechazada · vencida), que la propia cuenta puede consultar esa lista con el correo enmascarado y nunca el enlace de otra persona, y que una persona rechazada retiene a la empresa —la decisión es de Tikin— y un enlace vencido se reenvía desde nuestra consola.

2026-09-11 — receta: onboarding de una empresa

No cambia ningún contrato. Nueva receta onboarding de una empresa: los cuatro momentos del alta de una empresa en Tikin Bonus (se registra, Tikin la verifica, la llave y sus límites, los empleados cobran), quién es dueño de cada uno, y una lista de control que se comprueba por API y no por memoria. TIKIN-521.

2026-09-20 — la cuenta emprendedor

No cambia ningún contrato de la API pública: Account.type sigue siendo person | business. Lo que cambia es el producto Tikin: además de personal y empresa, una persona puede abrir una cuenta emprendedor, y conviene saber cómo se ve desde afuera.

• Un emprendedor es una persona natural que emprende: abre con la misma cédula y el mismo KYC que una cuenta personal, y declara su negocio (nombre comercial y actividad). En la API pública aparece como type: person, con el alias de su negocio.
• El RUT sube, no abre. Sin RUT validado la cuenta opera con los topes de persona; con el RUT validado pasa a los de emprendedor. La validación la hace el equipo de Tikin; no hay endpoint público para ello.
• Una misma persona puede tener cuenta personal, emprendedor y empresa, cada una con su propio alias y su propio cupo.
• Los topes por tipo y nivel están escritos en verificación y cumplimiento.

Cuando el contrato público distinga al emprendedor (type: entrepreneur), se anunciará aquí con antelación: hoy sería una promesa sin backend detrás.

2026-09-10 — alta de staff y gobierno del acceso (pendiente de promoción)

Contrato privado del ledger, disponible para la consola interna tras su promoción: POST /v1/admin/staff/subjects crea sujeto, primer rol de plataforma o grant de tenant y bitácora atómicamente. Exige platform.staff.create y el permiso del grant, rechaza sujetos duplicados (409) y auto-otorgamiento de PLATFORM_ADMIN (403). La consola busca la persona por nombre, correo o documento, la revalida en el servidor y exige PIN.

Las altas implícitas de POST /v1/admin/staff/grants también exigen el permiso propio; los administradores de tenant asignan roles a sujetos ya incorporados por plataforma. El cambio no agrega rutas a api.tikin.is ni activa enforcement. El paso LEDGER_RBAC_ENFORCE=off → log → 1 requiere dos admins activos, grants de operadores, bitácora revisada y decisión de Angel. Gobierno y /v1/admin/authorize siempre exigen permisos, incluso en sombra/log. La referencia contractual vive en x-staff-access de openapi/tikin.yaml y el procedimiento operativo en el runbook del ledger.

2026-09-10 — la verificación, explicada de punta a punta

No cambia ningún contrato: verification sigue siendo unverified | verified y account.verified sigue siendo el único evento de identidad. Lo que cambia es que ahora está escrito qué hay detrás, porque tener el estado sin entenderlo no alcanza para operar.

Nueva página: verificación y cumplimiento — la regla de "recibe pero no envía", los tres estados de una cuenta (restringida, habilitada, bloqueada) y en qué se diferencian para tu soporte, los cuatro momentos en que se revisa una cuenta (al abrir, al pagar, por revisión periódica y por monitoreo), qué hacer cuando una queda retenida, qué motivos de rechazo admiten un segundo intento y cuáles no, y cómo funciona la verificación de una empresa.

Tres cosas que la página declara explícitamente que hoy no existen, para que nadie las asuma:

• No hay webhook por cada cambio de estado de cumplimiento. Solo account.verified. Que una cuenta pase a retenida, o que el monitoreo la levante después, se consulta — no llega.
• Los estados con grano no están en el API: restringida, habilitada y bloqueada son el modelo interno; el recurso Account sigue exponiendo dos valores. Llegarán como valores nuevos y aditivos.
• El detalle de un hallazgo no viaja nunca al tenant — ni el motivo, ni el score, ni la evidencia. Es una decisión de diseño, no una carencia: la página trae los tres únicos mensajes que se le pueden mostrar a la persona.

Referencia: verificación y cumplimiento · Identity · Accounts.

2026-09-10 — contratos internos del admin (pendientes de promoción)

El plano privado de operadores incorpora autorización viva en el ledger, evidencia firmada antes de capturar retiros manuales y paginación completa de la consola de rails. Son contratos entre servicios y el backoffice; no agregan rutas a api.tikin.is ni permisos a tokens de tenants. Las descargas sensibles comprueban pertenencia y registran autorización antes de leer los bytes.

Contrato y orden de promoción. Los PRs se revisan por separado: ledger-service apunta a qa; payment-rails a main. Esta entrada anuncia el contrato propuesto, no afirma que esté desplegado.

2026-09-10 — catálogos de Accounts (pendiente de activación)

El flip TIKIN-555 habilita las lecturas públicas en inglés /v1/catalog/*: países, países por proveedor, documentos, monedas, redondeos y T&C vigentes. Los clientes actuales conservan /masterdata/v1/* con las mismas formas de respuesta e identificadores. Las rutas nuevas quedan disponibles después de migrar los datos de cada entorno y activar el gateway.

Las listas usan IDs numéricos históricos; no son los UUID del catálogo de wallets. countries/provider/{name} devuelve code, mientras el detalle de país usa isoCode. Los T&C conservan el texto y la versión de cada entorno; ante un país sin términos se devuelven los de Colombia. Los arrays se ordenan por ID y los createdAt conservan su formato histórico sin zona. Son lecturas públicas, sin Bearer de tenant ni escritura de dinero.

Referencia: Catálogos de Accounts y Términos de Tikin.

2026-09-10 — lotes de Producto Tikin por el libro

La subida de Excel de Producto Tikin deja de depender de los endpoints retirados validate y bulk de Bloque. Se conservan las validaciones del archivo y la confirmación explícita de la dispersión. El libro decide saldo y reglas aplicables al ejecutar cada fila; el Excel de resultados muestra pagos confirmados y rechazos.

La validación inicial no reserva fondos. Rutas, estados y límites del reenvío se explican en Lotes de Producto Tikin. Este cambio de compatibilidad no modifica /v1/bonus_batches de Plataforma.

2026-09-09 — el país del beneficiario, y el historial que sí filtra

POST /v1/payouts acepta el país del beneficiario

destination.holder.country — ISO 3166-1 alpha-2 (CO, VE, ES) — es el país del beneficiario, y es lo que el screening de cumplimiento evalúa antes de soltar la plata. Se normaliza a mayúsculas: co y CO son el mismo país.

• Cambio aditivo y opcional: nada de lo que ya integraste se rompe, y api_version no cambia. Cuando el campo no viene se asume CO, el único país en el que Tikin paga hoy.
• Un valor que no sea alpha-2 —COL, Colombia, un número— se rechaza con 400 invalid_field. No cae al default: un ES ignorado sería un screening contra el país equivocado, y eso se parece demasiado a un screening hecho.
• Aviso anticipado: el día que exista un riel fuera de Colombia el campo pasa a ser obligatorio y el default desaparece. Se anuncia acá antes de que ocurra. Mándalo desde ya si tu beneficiario no reside en Colombia.

Vale para los dos destinos, bank_account y cash_pickup. Está en la receta del payout a banco y en el spec.

El historial ya honra sus filtros

El historial aceptaba filtros y los descartaba en silencio: alguien marcaba "solo de salida" y seguía viendo sus entradas, sin un error en ninguna parte. Ya no. Los filtros se aplican dentro de la consulta al libro —no sobre la página ya traída— y uno ilegible ahora es 400 en vez de una lista sin filtrar.

Qué se puede pedir, con qué semántica exacta, y las dos casillas que no dicen lo que parecen (cash_withdrawal devuelve vacío; add_funds incluye las reversiones): el historial y sus filtros.

Esto es semántica del libro. En api.tikin.is, listar movimientos sigue exponiendo el subconjunto de siempre (asset, kind, created_at[gte], created_at[lte]) y su contrato no cambia; el resto de los filtros se anunciará acá cuando llegue.

El titular que el cumplimiento exige

El dominio Accounts compone y expone cuatro datos del titular de una cuenta que antes no daba —nombres y apellidos separados, paisResidencia y paisNacimiento— porque un screening no puede trabajar con un nombre pegado. Nunca se derivan: lo que no se puede afirmar viaja null, y null retiene. Detalle en Accounts.

Es superficie interna del dominio: no está en api.tikin.is ni en el Account de obtener una cuenta. El día que llegue al API de tenants se anuncia acá.

2026-09-08 — las escrituras están vivas

POST /v1/transfers, POST /v1/bonuses, POST /v1/payouts, GET /v1/payouts/{id} y POST /v1/quotes ya responden en api.tikin.is — el playground de esta documentación dispara contra producción real.

• Las transferencias y los bonos se asientan síncronos en el libro; el payout entra a la cola de operación y avanza por sus estados (received → approved → in_progress → completed).
• La comisión sale de la escalera de tarifas de tu tenant (consultable sin mover nada con POST /v1/quotes); en las respuestas, un fee de 0 es un fee que no se cobra — el patrón de Money.raw ahora lo admite (^(0|[1-9]\d*)$).
• Reintentar con la misma Idempotency-Key devuelve 200 con el header Idempotent-Replay: true; la misma llave con otro cuerpo es 409 idempotency_key_reused.

Aún no disponibles (el contrato ya los define; se anunciarán aquí): transferencias entre tenants (destination.type: platform_account), listados (GET /v1/transfers, GET /v1/payouts, GET /v1/bonuses), POST /v1/payouts/{id}/cancel, bonos por lote y GET /v1/events.

2026-09-08 — nace el API v1

La primera versión pública del API de Tikin para tenants:

• Cuentas: crear, consultar, lookup por alias/teléfono, y declarar verificación (KYC) — la regla de la plataforma: sin declarar, la cuenta recibe pero no saca.
• Saldos y movimientos: la verdad del libro, con available y held por asset — jamás un cero falso.
• Transferencias: internas y entre tenants, síncronas, con idempotencia obligatoria.
• Bonos: individual (síncrono, fee desglosado) y masivo (el lote en tres actos: subir → revisar → disparar).
• Payouts: a cuenta bancaria o efectivo en punto, siempre asíncronos, con reserva inmediata y el estado returned contemplado desde el día uno.
• Webhooks: entregas firmadas (HMAC-SHA256 en Tikin-Signature) con reintentos.

Los tres principios del contrato — montos como texto, Idempotency-Key en todo lo que mueve dinero, errores que hablan — están documentados en Conceptos y no van a cambiar sin versión nueva.