> ## Documentation Index
> Fetch the complete documentation index at: https://docs.listo.delivery/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Notes on the Listo Partner Delivery API:
> - Every endpoint is under `https://api.listo.delivery/v1/` and authenticates with a bearer API key.
> - This documentation site is at https://docs.listo.delivery. The full machine-readable reference is the OpenAPI document at https://api.listo.delivery/docs/openapi.yaml (served by the API host, not by this site).
> - Any page of this site is also available as raw markdown by appending `.md` to its URL, for example https://docs.listo.delivery/en/guides/webhooks.md. The index of every page is https://docs.listo.delivery/llms.txt and all of them in one file is https://docs.listo.delivery/llms-full.txt.
> - Every page is published in English under https://docs.listo.delivery/en/ and in Spanish under https://docs.listo.delivery/es/, with the same path after the language. The API reference is under https://docs.listo.delivery/api-reference/ in English and https://docs.listo.delivery/es/api-reference/ in Spanish.
> - To debug an integration yourself: `GET /v1/request_logs` lists the calls your keys made with what you sent and what was answered, `GET /v1/events` lists the events Listo emitted, `GET /v1/webhook_deliveries` lists every attempt to deliver them, `POST /v1/events/{id}/resend` sends one event again and `POST /v1/test_webhooks` sends a sample event (`"test": true`). The page https://docs.listo.delivery/en/guides/debugging describes them. A resent event is a snapshot from when it happened; `GET /v1/deliveries` is still how you recover current state.
> - Every error response has `error.doc_url`, a page that explains that error code and what to do, and `error.request_id`, the same value as the `X-Request-Id` response header. All the pages are listed at https://docs.listo.delivery/en/errors. Filter `GET /v1/request_logs` with `request_id` to read the logged call.
> - A `409 account_exists` from `POST /v1/stores` means the restaurant already has its own Listo account: connect it instead of creating it, as the page https://docs.listo.delivery/en/guides/connect-existing-account describes.
> - On Listo's self-serve pricing the stores your account created itself carry no Plan Listo: `plan` is `null`, there is no Plan Listo per store, and the account pays for each trip and for the add-ons it switches on (monthly ones each month, per-use ones each time they are used). A restaurant that connects to a self-serve account keeps its own plan and pays it itself. On any other account every live store carries one Plan Listo, charged to the partner, unless the agreement has each restaurant pay its own. The exception is a connected restaurant that had already paid its current month: it keeps paying its own plan until its next renewal, shown as `paid_by: "store"` with the handover date in `pending_paid_by_on`. A `402 plan_required` from a quote, a delivery create or a retry means the store's plan is not paid or has ended (a store created by a self-serve account is never refused for lack of a plan, but it can still be refused with `402 plan_required` when Listo has switched its couriers off, and then the message says to contact Listo and nothing you pay changes it); the page https://docs.listo.delivery/en/guides/plan-and-billing describes the plan, the `plan` block on a store and how to end or restart it.
> - An AI assistant (Claude Code, Cursor, Codex, ChatGPT) can act on a developer account at `https://api.listo.delivery/mcp`, an MCP server over Streamable HTTP. A person connects by signing in (OAuth: the client opens a browser, the person signs in, chooses the account and allows it, optionally read-only); a script sends `Authorization: Bearer <API key>` instead. A sign-in access token works on `/mcp` only, never on `/v1/`. Every tool runs the matching `/v1/` endpoint, and each one that moves money first previews and then needs a confirmation token; the page https://docs.listo.delivery/en/guides/connect-ai-client lists the tools and describes the two steps.

# order_value_over_cap

> El pedido vale más que el límite de esta tienda para su tipo de pago, así que no se creó nada.

| Estado HTTP | Se puede reintentar |
| - | - |
| `422` | No, cambia primero la petición o el estado |

## Qué significa

El pedido vale más que el límite de esta tienda para su tipo de pago, así que no se creó nada.

## Causas comunes

* Un pedido ya pagado (prepaid) cuyo order\_value\_cents supera el límite de pedidos ya pagados de la tienda.
* Una cotización sin payment\_method y con un order\_value\_cents por encima del límite de pedidos ya pagados de la tienda (una cotización sin método de pago se juzga como ya pagada, porque solo una entrega ya pagada puede reservarla).
* Un pedido con tarjeta (card) cuyo order\_value\_cents supera el límite de pedidos con tarjeta de la tienda.

## Qué hacer

* Lee los order\_value\_limits de la tienda (GET /v1/stores/{id}) para ver sus límites de pedidos ya pagados y con tarjeta.
* Divide el pedido en entregas más pequeñas, o manda uno que valga menos que el límite.
* Contacta a Listo para subir el límite de esta tienda.
* El efectivo tiene su propio límite y su propio código, cash\_over\_cap.
* error.param es order\_value\_cents. No se creó nada, así que puedes volver a usar la misma Idempotency-Key cuando se suba el límite.

Toda respuesta de error trae un `error.request_id`. Cítalo si escribes a soporte, y lee [Depurar tu integración](https://docs.listo.delivery/es/guides/debugging.md) para buscar la llamada tú mismo.

[Todos los errores](https://docs.listo.delivery/es/errors.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.