Soporte y exhaustividad de los datos

La advertencia sobre exhaustividad, dicha sin rodeos

La API de partners expone los registros capturados después de que la funcionalidad se activara para ese restaurante, tanto las entregas como las colecciones. No pretende contener el historial completo de un restaurante, y no lo va a rellenar.

Esto importa más de lo que parece:

• Un resultado vacío no es prueba de que no ocurriera nada. Puede significar que el restaurante aún no estaba activado, o que un dispositivo todavía no ha subido los datos.
• Un recuento de esta API no es una cifra de cumplimiento. No lo imprima en un informe que se lea como una auditoría.
• Si necesita saber la fecha de activación de un restaurante, pregúntenos o pregunte al cliente. Ahora mismo no se expone a través de la API; si la necesita como campo, díganoslo y pasará a serlo.

Las colecciones lo dicen en su propia respuesta: stateKind es received-shadow-snapshot, es decir, el estado que recibió esta API, no el estado que tiene la aplicación del restaurante. Los dos coinciden en el caso corriente y divergen exactamente cuando un dispositivo todavía no ha subido los datos.

Una vez activado un restaurante, los registros llegan de forma fiable, incluidos los capturados mientras un dispositivo estaba sin conexión: esos se suben cuando vuelve a conectarse, y por eso las consultas incrementales deben solaparse y por eso capturedAt y receivedAt están los dos en cada registro.

Versionado

Todas las rutas llevan el prefijo /v1. Dentro de esa versión sí vamos a:

• añadir campos a una respuesta, y
• añadir endpoints y parámetros opcionales.

Ambas cosas son retrocompatibles, y ninguna se anunciará como un cambio incompatible, así que analice con tolerancia: ignore los campos que no conozca en lugar de fallar por ellos.

No eliminaremos un campo ni le cambiaremos el tipo, no cambiaremos el significado de uno existente ni haremos obligatorio un parámetro opcional dentro de /v1. Todo lo que lo necesite llegaría como /v2, junto a /v1, con aviso.

El documento OpenAPI se genera a partir del servicio en ejecución, así que es la descripción autorizada de lo que está desplegado ahora mismo. Si esta documentación y ese documento no coinciden, el documento tiene razón y nosotros tenemos una página que corregir: díganoslo.

Comprobaciones de estado

Dos endpoints públicos, sin autenticación:

/health/ready es el que conviene consultar si nos monitoriza. Los sondeos correctos no se registran en la auditoría, así que un monitor no añade ruido.

Conseguir ayuda

Escriba a contact@backresto.com. Lo que hace que una respuesta sea rápida:

• el requestId del documento de problema, o el X-Request-ID que envió;
• el prefijo público de su clave —la mitad brp_… anterior al punto, nunca el secreto—;
• el entorno, el endpoint y, aproximadamente, cuándo.

Nunca nos envíe el secreto de una clave: el prefijo público la identifica sin ambigüedad. Si un secreto ha ido a parar donde no debía, dígalo en el asunto y envíe el prefijo: la revocación es inmediata, y es el remedio completo. Consulte Obtener una clave para el resto del ciclo de vida de una clave.

Pedir más

Lo que existe aquí existe porque alguien lo pidió. Las temperaturas de cocción y enfriamiento, los planes de limpieza, las etiquetas y un endpoint MCP alojado estaban todos en esta lista hace unos meses; ahora son colecciones y un endpoint.

Lo que sigue en ella: webhooks en lugar de consultas, un cursor incremental en las colecciones, una fecha de activación en el restaurante, y el inicio de sesión OAuth para los clientes MCP que no aceptan una clave. Cuál viene después lo decide quién lo pide. Así que pídalo.