Versión en español: https://acform.es/bot

LisvaroApp: the Lisvaro crawler

Lisvaro is a mobile app that watches the price of the products each user adds by hand, and alerts them when it drops. This page explains exactly what our agent does when it requests a page from your site, and how to exclude it if you would rather it did not.

Identification

Normal requests identify themselves like this:

LisvaroApp/1.0 (+https://acform.es/bot)

Until August 2026 this application was called Precio and identified itself as PrecioApp. Nobody uses that name any more. If you have it in a robots.txt rule, read How to exclude us: it needs changing.

Some product pages do not publish the price in the HTML: their JavaScript paints it after loading. For those — and only those, after trying the normal path first — the app opens the page in the phone's own browser (the system WebView), which identifies itself with its usual User-Agent, the same one you would see if that person opened your site by hand. We do not falsify that string in either direction: we do not put ours on a real browser, and we do not put a browser's on our client.

The robots.txt is always requested as LisvaroApp, including when the page is going to be loaded by the browser. That way the exclusion described below works in every case.

And when we load your page in that browser, we block image downloads, always and without exception: we only care about the price. On an Amazon product page that brings the load down from 4,290 kB to 1,140 kB measured. It saves you bandwidth and saves the user data.

What it does

• Downloads only the exact address the user added. It does not crawl, does not follow links, does not discover products, does not walk catalogues or sitemaps.
• Extracts price, currency and availability, preferably from structured data (schema.org, microdata, Open Graph).
• Waits at least one hour between two checks of the same product, and spaces out consecutive requests to the same domain. That floor cannot be switched off from the app, and it applies to shops we read through an official API too: until 12 August 2026 the floor was thirty minutes, and fifteen for the API; both were raised.
• If your page needs the browser to give up the price, the product starts at six hours between checks instead of the three that any other one starts at: the read is more expensive for both of us, and there is no point repeating it that often.
• On repeated failure it backs off, spacing retries up to a maximum of one day, so as to stop insisting on something that does not work.
• Honours the Retry-After header.
• On a 429 it disables tracking of that product and tells the user. A 429 is never retried by any other route: that is your server saying "you are going too fast", and the answer is obeyed as given.
• On a 403 it makes one single second attempt, loading that same page in the phone's browser. The reason is that a 403 is hardly ever answered by the store: it is answered by its CDN by default, sometimes contradicting the site's own robots.txt, which expressly allows us that path. If the browser also finds the door closed, then it really is a no: the product is disabled and the user is told. There is never a third attempt.
• If your server accepts the connection and answers nothing at all, that same single retry with the browser is made, for the same reason. A genuine network failure — no DNS, no signal — is not retried.

Every request comes from the connection of a specific user's phone that asked to watch that product. There is no server of ours requesting your pages.

What it does not do

• It does not solve verification challenges. If your site asks to check there is a person behind the request, the app shows it to the user in a visible browser so that they answer it. That is the only honest answer to that question: automating it would be answering yes to something whose answer is no.
• It does not log in on its own and does not access private areas. If a page requires identification, the app stops and tells the user.
• It does not copy or republish your content. It stores the price, the previous or crossed-out price if you publish one, the currency, the availability, the date, the product name, the name of the version the user follows and the address of its image. It stores no descriptions and no text. The image is downloaded by the phone from your server when the user looks at the product — and only if they have turned images on, which is off by default — and the system keeps a copy in the phone's own cache so as not to ask you for it again every time the list scrolls. It is exactly what a browser does with any image on your site, and that copy is deleted when the app's data is cleared.
• It does not interact with carts, forms, coupons or checkout processes.
• It does not crawl. It never requests a URL that a user has not expressly added.

Data

Everything is stored on the user's phone. There are no central servers, no profiles and no collection of browsing data. We cannot see what anyone is watching. There is no centralised copy of your store's prices: we do not share it, publish it or sell it, because we do not have it.

Why the traffic comes from many different IPs

Lisvaro is not a centralised crawler. Each request is made by the phone of a specific user who asked to watch that product, from their own connection.

The practical consequence is worth knowing: requests arrive from many different residential IPs and there is no range you can block. The only stable thing is the User-Agent string. That is why we always identify ourselves the same way, and why this page exists: it is the only way for you to say "no" and to verify that we comply.

In terms of volume, each user only checks the products they have saved, and each of those at most once every half hour.

On impersonation

Anyone can write LisvaroApp in their own User-Agent. We cannot prove by IP that a request is ours, because they do not come from any infrastructure of ours, and we are not going to pretend otherwise.

If you see traffic identifying itself as LisvaroApp whose behaviour does not match what is described here — high volume, link traversal, bursts, attempts to reach private areas — write to us with a sample of your logs. We want to know, and we will help you characterise it.

How to exclude us

With robots.txt — active and working

This is the recommended method and we obey it:

User-agent: LisvaroApp
Disallow: /

We also honour partial rules (Disallow: /private/), Allow directives, and Crawl-delay when it is stricter than our minimum interval. We fetch the file before the first read of each origin and cache it for 24 hours.

If your server returns a 5xx error for the robots.txt, we do not fetch the page: we would rather wait than assume permission when the file might exist.

By email

Write to info [at] acform.es stating the domain. It is also the channel for any question, complaint or request about the agent's behaviour: we answer.

You do not need to justify or explain the request. The only thing we need to check is that the domain is yours: write from an address at that domain, or from the contact published on it. It is not a hurdle to put you off and we will not argue about your reasons; it is the only thing stopping someone from excluding a site that is not theirs.

You can choose how far we go

Tell us which of the three you prefer. If you do not say, we apply the second one:

• Lower frequency. We keep reading the price, but at most once a day per product and never opening the page in the browser. This is the right answer if your concern is load.
• Manual only. We stop requesting your pages on our own. Anyone who already had your products saved keeps them, and updates the price by opening your page themselves.
• Full exclusion. The above and, in addition, your domain can no longer be added to the app.

The robots.txt rule above is equivalent to "manual only": we stop requesting the page, and what a user then does with their own browser is not governed by that file.

Contact

info [at] acform.es