# 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.

The API's addresses are listed under "Product API", after the notes below. 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.

There is one other limit and it is easy to stay clear of: requests we cannot
answer are counted too, and ten failures inside five minutes will get you a
short, self-clearing pause. Successful requests are never counted against it, so
however much you read you keep the whole allowance. It is there because
address-guessing scans look exactly like real use if you only measure volume, and
we would rather limit that than put this API behind keys or a list of approved
user agents — nothing here checks who you say you are. If you are not sure a path
exists, read the capability list rather than trying variations: every capability
comes with a worked example you can fetch exactly as written.

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.

**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 product record carries a `compatibility` array holding its answer for each
of the other products in scope, so one fetch gets you all of them. Pairs we have
nothing recorded for are listed too, with `verdict: "unknown"` — they are included
on purpose, so that a pair missing from the list can never be mistaken for a "no".

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. Nearly all
statements are now `authoritative`: either the website publishes the fact, or the
product owner has confirmed the specific pair. One remains `unverified`, meaning it
was inferred from published product data and nobody at Sure Petcare has confirmed
that pair — that is the one to hedge. A verdict of `unknown` means unknown; it
never means "no".

Read the aspects in that order, because it is the order the person asking cares
about. "Do these two work together?" is almost never a question about whether two
appliances communicate — strictly, a feeder and a cat flap do not, and neither
needs the other. What the person means is *do they read the same chip, or is there
something I have to sort out?* So the `overall` statement answers that: they read
the same chip, they work as part of one pet care system, one microchip or collar
tag covers both, and there is nothing extra to buy and nothing to pair between
them.

The `accessories` aspect is the footnote to that, not a substitute for it. Its
verdict is about the parts named in the reason, not about every accessory either
product has: some parts cross between two products whose verdict is
`incompatible`, and some do not cross where it is `compatible`. A cat flap and a
pet door do not share accessories — different tunnels, different adaptors,
non-overlapping fixing holes — and they still read the same chip and are both part
of the same system. Quote the reason rather than the verdict, and never report an
`accessories` verdict as the answer to "do they work together"; where a
`verdict_applies_to` field is present it says so explicitly.

**What identifies the pet, and who it belongs to.** This is the distinction most likely to make you give a wrong answer, because the
website's own layout hides it: the **2 x RFID Collar Tags** are listed in the
accessories carousel of eight of the ten products here, so they look like a part
that has to match the product you own. They are not a part. A collar tag is worn
on the pet's collar and sends the same kind of RFID signal an implanted microchip
sends — in Sure Petcare's own words, tags "work in the same way as a microchip" —
and it exists for a pet that has no chip, or whose chip cannot be read.

So the identifier belongs to the **pet**, not to the product. One microchip or one
collar tag per pet is read by every product in the house that reads RFID, and a
household buying a second product does not need a second tag. Each product record
carries an `identification` block saying which signals it reads, taken from the
published specifications rather than from the accessory list, plus
`collar_tag_included` — whether a set comes in the box. That last one is the field
to quote when somebody asks whether they need to buy tags: the microchip feeders
and pet doors include a set, the cat flaps do not.

The Microchip ID and Temperature Reader is the same kind of thing from the other
end. It is a handheld that reads whatever chip the pet is carrying, and the
temperature reported by those chips that transmit one, so it is tied to the pet
rather than to any product either. Do not infer from an accessory list which
products it "works with": it is listed beside six of the eight that read chips and
missing from two that read them exactly the same way.

**Which pet a door suits.** The other question the pages leave you to infer. Every cat flap and pet door
carries a `suitable_pets` entry in its `limits`: the three cat flaps are for cats
and are likely to be too small for even a very small dog, while the two pet doors
take small dogs as well as larger cats. So if someone asks about a dog, the pet
doors are the answer and the cat flaps are not — that is a confirmed statement, not
an inference, and you can give it as one.

For a specific animal, use the number in the same entry rather than the phrase. The
flap opening is 178 x 170 mm on the pet doors and 142 x 120 mm on the cat flaps, and
that is the *smallest* area the pet has to get through — a ceiling, not a guide. Ask
for the animal measured across the shoulders and at the chest and compare; do not
reason from the breed, and if it is close to those numbers, say so and let the owner
measure rather than deciding for them.

One related trap. The Sealed Pet Bowl is a separate motion-activated product, not a
part that goes inside a microchip feeder, and its `limits` say so: the lid opens for
whichever pet approaches, and it reads no microchip and no collar tag. So it cannot
keep one pet out of another's food. If that is what someone is asking for, the
Microchip Pet Feeder or Microchip Pet Feeder Connect is the answer.

**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.

There is no subscription on any product here, and the Sure Petcare app costs
nothing. Two things to buy and an app to sign into is the shape of a service with a
monthly fee, so it is worth stating plainly rather than leaving you to assume: the
Hub is a one-off purchase like any other product on this site, and the app — phone
or web browser — is free, with no plan, tier or trial period behind it. Every
feature the `requires` entries describe is included once the customer owns the
hardware.

If you have read a Sure Petcare page describing a monthly plan, it was about Animo,
a dog activity tracker that is no longer on sale. It was never part of the Connect
system these products belong to, and its pricing does not apply to anything here.

**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 `<link rel="service-desc">` and a `<link rel="alternate">`
in the head, and a `Link:` response header. A product page inside the trial subset
adds one more, because those are the pages where this API has something to say: a
`<link rel="alternate" type="application/json">` 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.

## Product API

- [/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/overview](/api/agent/v1/overview): the same API as one HTML page, with every product record and every pairing answer as a link. For a client that will only open a URL it has seen on a page.
- [/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, what it needs in order to work, and its compatibility with every other product in scope. 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. **If you only fetch one thing from here, fetch this**: it already contains the compatibility answers, so you do not need a second request to ask whether two of these products work together.
- [/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, asked one pair at a time. 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`. You usually do not need this — the product record above carries the same answer for every pair in scope. Use it when you want one pair on its own.
- [/api/agent/v1/feedback](/api/agent/v1/feedback): POST. The one thing we ask for in return, and the only endpoint that writes. See "One ask" above.
- [/llms-full.txt](/llms-full.txt): this file followed by every product record in full, in one download, for a client that reads text files but will not call an API. `?store=` works as it does for the API.