Distributor demo storefront, built on the PIMento API Sign in

2-Passenger

Showing 1–1 of 1

2019 E-Z-GO Burgundy RXV.. 2019EZGORVX-1

API reads behind this page 4 over the wire, 7 from cache · 318 ms total

Method	Path	Source	Status	Time
GET	/v2/slugs/2Passenger	network	200	18 ms
GET	/v2/categories/130	network	200	7 ms
GET	/categories/103	cache 5m	—	—
GET	/categories/156	cache 5m	—	—
GET	/categories/101	cache 5m	—	—
GET	/categories/100	cache 5m	—	—
GET	/products?$filter=requireLogin eq true&$select=productId	cache 1m	—	—
GET	/v2/categories/130/subcategories	network	204	7 ms
GET	/v2/categories/130/products?$top=24&$skip=0	network	200	286 ms
GET	/categories	cache 15m	—	—

204 and 404 both mean “no rows” on this API — which of the two an endpoint uses is per-endpoint, and the client maps both to an empty result rather than an error. Collections come wrapped in an OData envelope and are capped at 100 rows per page.

Rows marked cache were answered from memory, and the time beside each is how long that kind of read is held; one marked asked twice is something this page had already read while rendering, so it cost nothing either way. Catalog reads are cached by rate of change rather than on one site-wide timer:

Slugs 1h
Vehicles 1h
Identity (/me) 30m
Brands 30m
Item attributes 30m
Navigation 15m
Categories 5m
Product structure 1m
Anything absent 1m
Price and stock never cached

Pricing and stock are read live on every view — there is no setting that caches them. That is why a warm product page still makes exactly one request: everything else on it came from memory.

The catalog can also drop all of it at once rather than waiting for a tier to lapse, by calling POST /hooks/cache when it publishes.