cifraHQ Enterprise
API

REST-first. El mismo contrato para la UI y los integradores.

OpenAPI 3.0 público, auto-save por PATCH, concurrencia optimista con RowVersion y webhooks. La interfaz que usa cifraHQ es la misma que usted consume.

Solicitar demo Ver arquitectura
Los cuatro compromisos

Lo que hace a esta API distinta

Contrato

OpenAPI 3.0 público

El mismo spec que consume nuestro frontend. Sin API privada que usted tenga que suplicar.

Concurrencia

RowVersion en todo

Cada entidad lleva un <code>RowVersion</code>. Los 409 Conflict regresan el estado actual completo para resolver.

Auto-save

PATCH en cada campo

Sin botón guardar. El cliente encadena <code>RowVersion</code> devuelto para pipelining.

El patrón REST

CRUD + PATCH + sub-recursos para transiciones

  • CRUD estándar en cada recurso: GET /api/invoices, POST /api/invoices, GET /api/invoices/{id}.
  • PATCH para actualización parcial. Cada cambio de campo es un PATCH independiente. No hay "guardar documento" — hay 40 PATCH que se encadenaron.
  • Transiciones de estado como sub-recurso POST. POST /api/invoices/{id}/post, /approve, /void. Semánticamente claro; nunca un PATCH que muta estado.
  • Filtros via query string. Convención ?field.operator=value, por ejemplo ?customerId.eq=12&status.in=Posted,Released.
  • Respuestas 409 útiles. Cuando RowVersion no coincide, la respuesta incluye la entidad actual completa. El cliente decide: merge, sobreescribir, descartar.
Auto-save real

Cómo funciona por dentro

  • Debounce en textos para evitar PATCH por cada tecla; valores numéricos y dropdowns disparan al perder foco.
  • Pipelining por entidad. Cada PATCH devuelve el nuevo RowVersion; el cliente lo usa en el siguiente PATCH. No hay espera sincrónica entre campos.
  • Validación tolerante durante borrador. La API acepta estados parciales mientras el documento está en Draft; solo al hacer POST /post se aplica la validación estricta.
  • Cola por sesión. Un mismo usuario editando la misma entidad serializa sus saves — no condiciones de carrera dentro de la misma sesión.
  • Post-commit side effects via Hangfire. Correos, PDFs, webhooks y cachés analíticos se encolan después del commit. La transacción principal no espera por ellos.
Webhooks e integración

Eventos de negocio, no eventos CRUD

  • Eventos tipados. invoice.posted, payment.applied, period.closed. No "row inserted".
  • Retries con backoff exponencial. Cola Hangfire con política configurable por categoría (post-transaction: 3 intentos).
  • Firma HMAC en cada delivery para verificación.
  • Auditoría del delivery visible en el panel de administración. Usted ve qué webhook falló y por qué.

Revise el spec con su equipo

Le compartimos el OpenAPI público y un sandbox para probar flujos de integración.

Pedir acceso