CartamaticPOS SDK

Toteat

Cobertura del adapter Toteat, endpoints, autenticación, límites y estado de estabilidad.

Toteat es el primer provider implementado por el SDK.

Cobertura actual

Toteat declara todos los métodos actuales como disponibles, pero algunas áreas siguen normalizadas de forma conservadora hasta validar más fixtures reales.

Base URLs

EnvironmentURL
productionhttps://api.toteat.com/mw/or/1.0/
developmenthttps://apidev.toteat.com/mw/or/1.0/

También se puede inyectar baseUrl para tests o entornos controlados.

Autenticación

Toteat recibe credenciales como query params:

SDKQuery param Toteat
restaurantIdxir
localIdxil
userIdxiu
apiTokenxapitoken

Por eso el SDK debe ser server-side y las URLs deben redactarse antes de logging.

Credenciales en query string

xapitoken, xir, xil y xiu son sensibles. Nunca loggees URLs Toteat sin redacción.

Mapping de endpoints

SDKHTTPPath ToteatQuery/body relevante
catalog.getProductsGETproductsactiveProducts
tables.getTablesGETtablescredenciales
shifts.getCurrentShiftStatusGETshiftstatuscredenciales
orders.getOrderStatusGETorderstatusic, body_detail_type
orders.createOrderPOSTordersbody order, query orderDetail
orders.notifyDispatchPOSTorders/dispatchbody despacho
orders.getCancellationReportGETorders/cancellation-reportstart_date, end_date
sales.getSalesGETsalesini, end, detail_cancel_order
sales.getSalesByWaiterGETsalesbywaiterinitial_date, final_date
sales.getCollectionGETcollectiondate
fiscal.getFiscalDocumentsGETfiscaldocumentsini, end, doc_type
inventory.getInventoryStateGETinventorystateinitial_date, final_date
accounting.getAccountingMovementsGETaccountingmovementsinitial_date, final_date, include_sales
purchases.createPurchaseMovementPOSTpurchasemovementsbody compra
raw.requestGET/POSTpath manualquery/body manual

Capacidades declaradas

pos.capabilities para Toteat declara todos los métodos actuales como disponibles.

Ventas

sales.getSales y sales.getSalesByWaiter tienen maxRangeDays: 15.

Fiscal e inventario

fiscal.getFiscalDocuments e inventory.getInventoryState validan rangos de 15 días.

Contabilidad

accounting.getAccountingMovements también limita el rango máximo a 15 días.

Validaciones del adapter

ValidaciónMétodos afectados
Fecha real YYYY-MM-DDreportes y sales.getCollection
Rango máximo 15 díasventas, garzones, cancelaciones, fiscal, inventario, contabilidad
endDate >= startDateendpoints con rango
Timeout positivotodas las requests
Retry no negativorequests GET con retry
HTTP status code válido en retryrequests GET con retry
Body order objeto no vacíoorders.createOrder
Strings no vacíosorders.notifyDispatch, purchases.createPurchaseMovement
lineDetails no vacíopurchases.createPurchaseMovement

Reintentos

Defaults Toteat:

OpciónValor
requestTimeoutMs30_000
readRetry.maxRetries1
readRetry.delayMs250
readRetry.statusCodes408, 429, 500, 502, 503, 504

Los retries solo se aplican a GET. Las escrituras POST nunca se reintentan automáticamente.

Estado de esquemas

El SDK valida envelopes y normaliza de forma conservadora. Varios samples públicos de Toteat colapsan objetos a {}, por lo que no deben tratarse como schemas completos.

Cómo endurecer schemas

Primero captura payload real, sanitiza fixture, agrega tests de schema y normalizer, y recién después endurece Zod.

ÁreaEstado
ProductosEnvelope validado, normalización conservadora.
MesasEnvelope validado; campos pendientes de fixture real.
TurnosCampos parciales.
ÓrdenesAcknowledgement y status normalizados de forma conservadora.
VentasEnvelope validado; filas conservadoras.
FiscalRespuesta directa array; campos parciales.
InventarioEnvelope validado; items raw.
ContabilidadEnvelope validado; aggregates raw/parciales.
ComprasAcknowledgement parcial.

Legacy

Algunos endpoints aparecen como legacy-only en documentación actual de Toteat. El SDK los implementa porque forman parte de la superficie requerida, pero deben validarse contra ambiente real antes de uso productivo sensible.

En esta página