# Benchmark: lookup handlers against real Odoo and WooCommerce containers

First-party measurements for the October 2026 Amazon Connect integration guides. Each run drives the **unmodified** handler (`../erp/handler.mjs` or `../bigcommerce-woocommerce/handler.mjs`) with real `fetch` against a local container, and reports p50, p95 and max latency plus a status histogram.

Results (October 28, 2026, Apple M4, Docker Desktop, localhost):

| Platform | Calls | p50 | p95 | max | Notes |
| --- | --- | --- | --- | --- | --- |
| Odoo 19.0 (JSON-2) | 200 | 10 ms | 11 ms | 13 ms | 3 API calls per lookup (partner search, then invoice count and latest order in parallel) |
| WooCommerce 11.2.1, legacy storage | 200 | 24 ms | 33 ms | 79 ms | `search` + client-side confirmation |
| WooCommerce 11.2.1, HPOS | 200 | 24 ms | 39 ms | 77 ms | same queries after `wp wc hpos enable` |
| WooCommerce + phone-lookup plugin, legacy | 200 | 31 ms | 37 ms | 93 ms | E.164 caller IDs only; 160 found, 40 ambiguous, 0 missed |
| WooCommerce + phone-lookup plugin, HPOS | 200 | 28 ms | 31 ms | 81 ms | same |

Full details: [`results-odoo-2026-10-28.json`](results-odoo-2026-10-28.json), [`results-woocommerce-2026-10-28.json`](results-woocommerce-2026-10-28.json).

**What these numbers mean.** They isolate the adapter plus the platform's own query time on a small dataset. They exclude network distance to a real host, TLS, caches/WAF, load, large tables, Connect-to-Lambda overhead and Lambda cold starts. On a real deployment, network round trips will dominate; measure from a Lambda in your Region against your staging host before choosing live lookup over a cache.

**Functional finding (WooCommerce).** A caller ID in E.164 form (`+15555550007`) returned `not_found` for an order whose billing phone is stored as `(555) 555-0007`, on both storage modes. WooCommerce's `search` matches the stored text, so phone lookup only works when the search term is in the stored format. The [phone-lookup plugin](../woocommerce-phone-lookup/README.md) fixes this by matching normalised digits; with it installed, no E.164 caller ID missed (rows 4 and 5).

## Reproduce

Odoo:

```sh
cd odoo && docker compose up -d
docker compose exec -T odoo odoo -d bench -i sale,account --stop-after-init --db_host db -r odoo -w odoo
docker compose cp seed.py odoo:/tmp/seed.py
docker compose exec -T odoo sh -c 'odoo shell -d bench --db_host db -r odoo -w odoo --no-http < /tmp/seed.py'   # prints an API key
cd .. && ODOO_URL=http://localhost:8069 ODOO_API_KEY=<key> ODOO_DB=bench BENCH_CALLS=200 \
  node bench.mjs erp odoo +14155550000 +14155550001 +14155550042 +14155550150 +14155550199 +14155558888 +14155559999
```

WooCommerce:

```sh
cd woocommerce && docker compose up -d
docker compose exec -T cli wp core install --url=http://localhost:8080 --title=Bench --admin_user=admin --admin_password=admin --admin_email=a@example.test --skip-email
docker compose exec -T cli wp plugin install woocommerce --activate
docker compose cp seed.php cli:/tmp/seed.php && docker compose exec -T cli wp eval-file /tmp/seed.php   # prints key + secret
docker compose exec -T cli wp rewrite structure '/%postname%/'
cd .. && WC_SITE_URL=http://localhost:8080 WC_KEY=<ck_...> WC_SECRET=<cs_...> BENCH_CALLS=200 \
  node bench.mjs commerce woocommerce '(555) 555-0007' '(555) 555-0150' '(555) 555-0199' '555-555-9999' '+15555550042'
# HPOS run: docker compose exec -T cli wp wc hpos sync && docker compose exec -T cli wp wc hpos enable, then run again
```

`woocommerce/mu/force-https-flag.php` exists only because WooCommerce accepts REST basic auth over HTTPS only and this local container serves HTTP. Never deploy it.

`node --test` checks the percentile and summary maths in `bench.mjs`.