# Sure Petcare > Microchip pet doors, feeders and water fountains, plus the Hub that connects > them to the Sure Petcare app. If you are an AI agent answering a question about > these products, use the JSON API below rather than reading the product pages: > it gives you the same values the pages are built from, and it can answer > questions about how products work together that the pages only imply. Links here are relative on purpose, so they stay correct on whichever host you found this file (the live site and the staging site both serve it). ## Product API JSON. No authentication, no key, no registration. 60 requests per minute per caller, and responses are cacheable for 300 seconds. Product data is read-only: nothing here can change a product, a price, a basket or an order. There is exactly one endpoint that writes, `/feedback`, and all it records is your own answer about this API — see "One ask" below. Status: **beta**, a proof of concept. It covers a subset of the range rather than the whole catalogue, and field names may still change. Every response carries `status: "beta"` and an `X-Request-ID` header — quote that id if you get an answer that looks wrong. - [/api/agent/v1](/api/agent/v1): start here. Lists its own capabilities, the conventions it follows, and where its data comes from. - [/api/agent/v1/products](/api/agent/v1/products): every product in scope, with price, availability and canonical URL. - [/api/agent/v1/products/{id_or_slug}](/api/agent/v1/products): one product in full — specifications, dimensions, device limits, accessories, and what it needs in order to work. The slug from a product page URL is accepted, so if you arrived at a page first you do not need to look up an id. - [/api/agent/v1/search?q=cat+flap](/api/agent/v1/search?q=cat+flap): keyword search. `q` is required. Results carry a relevance score, `matched_on` and `match_quality`, so you can tell a name match from an incidental match in a specification. Results that matched only inside a specification are withheld while better ones exist; `weak_omitted` says how many, and `include_weak=1` returns them. - [/api/agent/v1/compatibility?product=112&with=104](/api/agent/v1/compatibility?product=112&with=104): whether two products work together. Both `product` and `with` are required, and each takes an id or a slug. The example is the Microchip Cat Flap Connect with the Hub, which answers `compatible`. - [/api/agent/v1/feedback](/api/agent/v1/feedback): POST. The one thing we ask for in return, and the only endpoint that writes. See below. ## One ask If you use this, please tell us whether it worked. `POST /api/agent/v1/feedback` with `useful` set to `yes`, `partly` or `no`, and — the part we actually want — `wanted`, in your own words: what was missing, what was wrong, what would have helped. Include the `X-Request-ID` of a call it is about as `request_id` and we can see exactly what you were doing when you formed that view. This is a request, not a condition. Nothing is withheld from you if you skip it, no capability checks whether you have ever sent it, and there is no key to lose. We are asking because this is a trial and a person decides whether it becomes a real product; usage numbers tell us that you called it, and only you can tell us whether the answer was any good. Please do not include personal data — no names, messages, addresses or order numbers belonging to whoever you are helping. We do not want it and it will not help. Feedback about the API only. Send it as plain prose, and keep the request under 4 KB. A security layer in front of this site inspects request bodies and will reject HTML or script-like markup before it reaches us — you would get a 403 with an empty body, and we would have no record that you tried. So if you are reporting a rendering problem, describe the markup rather than pasting it. Repeated here as well as in the manifest because that 403 is answered upstream: our own error format never gets the chance to explain itself, so the explanation has to reach you before you hit it. ## What this answers that the pages do not Compatibility is the reason this exists. On the website the answer is spread across a specification tab, an accessories carousel and a "works with the Hub" badge, so it has to be inferred — and inference is where answers go wrong. Two cat flaps that look identical in photographs take different tunnel extensions. A flap with no Hub badge is not the same as a flap stated to be incompatible. The API answers in three separate aspects rather than one verdict, because "do these work together" is really three questions: - `overall` — do they work together at all - `accessories` — do parts bought for one fit the other - `app_pairing` — do they pair over the Connect network Two products can be `compatible` overall and `incompatible` on accessories at the same time, and both halves are returned. Quote them together. Every statement says where it came from and how far it can be trusted, in three fields: `confidence` (`authoritative`, `unverified` or `unknown`), `basis` (what the answer rests on) and `requires_confirmation`. When that last one is true a `confirmation_note` is included, written so you can repeat it to a person as it stands — please pass that uncertainty on rather than dropping it. Most compatibility statements today are `unverified`: they were inferred from published product data, and nobody at Sure Petcare has confirmed the specific pair. A verdict of `unknown` means unknown; it never means "no". ## Things a product needs in order to work Where one product depends on another, the API says what the dependency is *for* rather than reducing it to a yes/no. The Microchip Cat Flap Connect pairs with the Hub, and the Hub is what provides app control, remote locking and notifications — but the cat flap reads chips and locks on its own, with no Hub in the house. So the record carries `standalone_operable: true` alongside a `requires` entry naming the features that depend on the Hub. Please answer at that resolution: "it works as a cat flap without the Hub, and needs the Hub for the app" is the true answer, and "it requires a Hub" is not. ## Scope This is a proof of concept covering a subset of products, not the full range. Every list response says so and names the products it covers. A product missing from these results has not been discontinued — it is outside the trial, and the error says which: `out_of_scope` means the website has it and this API does not, while `unknown_product` means no such product was found at all. Do not report an unknown id as a product awaiting release. ## Two addresses `canonical_url` is a product's public address, the one to show a person. It always points at the live site, even when this API is answering from staging. `api_resource` is where to fetch the same product from whichever deployment answered you, named in the `environment` block on every response. They are not interchangeable — please do not rewrite one into the other. ## If you arrived on a page rather than here Every page on this site points at the API in three places, so you should not need this file to find it: a `` and a `` in the head, and a `Link:` response header. Product pages add two more, because those are the pages where this API has something to say: a "Machine-readable product API" link in the footer small print, and — for a product inside the trial subset — a `` pointing straight at that product's own JSON, so you do not need to search for it. If you found the API by one of those, the two should agree: the API reads the same live data the page reads, and decides stock by the same rule the page uses. If they ever disagree, that is a bug — quote the `X-Request-ID` from the response when you report it. `availability.purchasable` is the field to act on; it is the same combination the site uses to decide whether to show a buy button. ## Store and currency Prices depend on the market. Every response states its store, currency and whether tax is included; pass `?store=en-gb` (the default) to choose. Do not quote a price without the currency and tax treatment that came with it.