The Mercadona CLI was designed from the ground up for AI agents and shell scripts. All data goes to stdout, all log messages and errors go to stderr, every command exits with codeDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/ivorpad/mercadona-cli/llms.txt
Use this file to discover all available pages before exploring further.
0 on success, 1 on error, or 2 on a usage error, and a spending guard actively stops agents before they can overspend. These properties make the CLI safe to pipe, parse, and orchestrate without special wrappers.
Output conventions
The CLI follows Unix conventions strictly, so standard tooling likejq, awk, and shell pipelines work without ceremony:
- Data → stdout, logs/errors → stderr. Your pipeline only sees clean output; error messages never contaminate JSON.
- Exit code
0on success,1on error,2on a usage error. Agents canset -eor check$?without parsing output. --jsonon any command emits machine-readable JSON. The flag can appear anywhere after the subcommand.- Safe to pipe immediately:
--json flag works on every subcommand — search, batch, product, categories, cart get, checkout create, and the rest.
Spending caps — critical for agents
When an agent drives the CLI, you must cap how much it can ever spend. Any cart or checkout command whose estimated total exceeds the cap is refused with a non-zero exit and anerror: line on stderr — the agent stops instead of running up a large order.
Pass --max <eur> on every cart and checkout command:
MERCADONA_MAX_EUR so every command in a script is automatically guarded:
0/unset means no limit. The set-many command prices the resulting basket before writing, so a cap breach leaves the cart untouched. checkout submit fails closed — with a cap set, if it cannot read the order total it refuses rather than pay blind.
The cart
--max covers only the product subtotal. The checkout --max must also cover the delivery fee (~8.20€). For a ~60€ basket, use --max 61 on cart commands and --max 70 on checkout commands.Idempotent cart writes with set-many
For agent workflows that build or replace a basket, cart set-many is the correct primitive. It performs a single GET, applies every <id> <qty> change atomically, and issues a single PUT — one round trip, no race conditions.
cart add calls in a loop. The cart backend is eventually consistent: a cart get fired immediately after a write may show the pre-write state for a beat, and back-to-back separate writes can race (the second read sees the pre-first-write cart and overwrites it). set-many sidesteps both problems entirely.
Use cart clear to empty the cart in a single write before rebuilding from scratch:
Agent workflow pattern
A safe, complete agent workflow for grocery shopping follows these steps in order:Resolve product names to IDs
Use
batch to translate natural-language terms to product IDs and prices in a single request (~100 items per call).Price the basket before touching the cart
Compute the total deterministically with
total. This is the pre-cart estimate; no login required.Set the cart atomically
Write the whole basket in one PUT. The
--max flag prices it first and refuses before writing if the total exceeds the cap.Create a checkout
Opens a checkout from the current cart and returns the checkout ID and default delivery address.
Attach delivery address and slot
Reserves the slot; the response carries the final price breakdown including the delivery fee.
JSON parsing with jq
The--json flag produces consistently structured output on every command. Common patterns:
search --json and batch --json) carries id, display_name, packaging, categories, and price_instructions (with unit_price, reference_price, reference_format). The cart shape (from cart get --json) carries id, version, products_count, lines, and summary.total.
Environment variables
All configuration that should not appear in shell history or process arguments can be passed via environment variables. The full set:| Variable | Purpose |
|---|---|
MERCADONA_TOKEN | Bearer access token (short-lived, ~6 weeks) |
MERCADONA_COOKIE | Session cookie accompanying the access token |
MERCADONA_CUSTOMER | Customer ID (decoded automatically from the token when omitted) |
MERCADONA_USER | Username/email for login (fallback; prefer import-har) |
MERCADONA_PASS | Password for login (fallback; prefer import-har) |
MERCADONA_MAX_EUR | Session-wide spending cap in euros — every command honours it |
MERCADONA_CONCURRENCY | Parallel price-fetch threads inside set-many (1–16, default 4) |
MERCADONA_CONFIG_DIR | Override the default config directory (~/.mercadona/) |
~/.mercadona/config.toml > cached token.json.
Rate limiting and concurrency
The CLI auto-retries HTTP 429 and 503 responses with backoff, honouring theRetry-After header. An occasional throttle appears as a short pause, not an error. To stay comfortably within rate limits:
- Use
batchinstead of many individualsearchcalls. A singlebatchrequest handles ~100 terms. MERCADONA_CONCURRENCYtunes the concurrent price-fetch burst insideset-many(default4, range1–16). Lower it if you see throttling during large cart builds.
IP sensitivity
Not all commands have the same network requirements:- Search (Algolia) — not behind Mercadona’s Akamai at all. Works from any IP, including CI, serverless, and datacenter egress.
- Catalog reads (
/api/...) — Akamai-fronted but served to anonymous GETs at human-paced volume. - Auth, cart, and checkout — IP-sensitive. These must run from a residential IP. Datacenter and serverless egress IPs are flagged by Akamai and trigger hard challenges. Run authenticated commands locally or on a box on your own network.