Here the estate is the dataset. A locker map that is a month old does not just look stale, it sends a customer to a machine that is no longer there.
Plans from €169 a month · Free project assessment · Reply within 1 business day
CSV · Excel · JSON · XML · FTP · SFTP · Amazon S3 · Google Cloud
API, JSON feed or CSV, XLSX and JSON files
ScheduleOne-time, monthly, weekly, daily or 3 times a day
InPost pages, filters, fields and a schedule
Built, monitored and repaired by our team
API, JSON feed or CSV, XLSX and JSON files
ScrapeIt builds and runs the collection as a managed service. You tell us whether you need a coverage study or a live feed for a checkout; we build the pipeline accordingly and hand back CSV, JSON, Excel or a push into your warehouse, with compartment sizes structured, hours by day and changes as their own records.
For anything customer facing we recommend frequent refresh with change detection rather than periodic full exports, because the estate moves fast enough that a stale map becomes a support cost.
We collect only publicly available data - locker addresses, compartment sizes, hours, payment options and status, everything a visitor can see on InPost - and we collect it legally, pacing requests as we go.
Each locker record carries the machine identifier, name, full address, postcode, city and voivodeship, coordinates, and the location description that tells a customer where to actually find it, which is often the difference between a usable map and a frustrating one.
Compartment availability is delivered as structured fields rather than prose: which sizes the machine offers, and the dimensional limits for each. This is the field that decides whether a parcel can be sent there at all, and flattening it into a text blob makes automated checkout filtering impossible.
Operational attributes cover opening hours structured by day, whether the machine is accessible around the clock, payment methods supported, whether it accepts returns and whether it is indoors or outdoors, which affects both accessibility and customer preference.
Status and change fields record whether a machine is listed as active, and each collection is compared with the previous one so additions, removals and relocations arrive as their own records rather than as a silent difference in a full reload.
Every row carries the collection timestamp, which on a fast moving estate is not decoration but the thing that tells you whether a record can still be trusted.
Coverage mapping is the analytical use of this dataset. Locker density against population, against a retailer's order distribution, or against competing networks answers where out of home delivery is a real option and where it is not. It is a one off study rather than a feed, and it runs off a single good collection.
Checkout integration is the operational use and it needs the opposite: a feed with change records, frequent enough that the map in the checkout matches the street. Those are two different products from the same source and we scope them separately.
Tracking is scoped on its own. The tracking surface answers one parcel number at a time, so shipment status is collected for the parcel numbers you supply. It screens automated clients, and anti-bot handling - pacing, proxy rotation and CAPTCHA handling - is part of the service.
Competitive comparison is a common extension: several locker and out of home networks collected together give a retailer a real picture of the delivery options available to its customers, rather than one network's view of itself.
InPost runs the parcel locker network that reshaped Polish ecommerce delivery, and the network is the thing that matters in its data. Out of home delivery has an unusually high share in Poland, and for a retailer selling there the locker map is not a convenience feature, it is a primary delivery option that customers actively choose.
The locker finder surface is public and responds, listing machines with their addresses and attributes. Tracking is a separate surface that answers one parcel number at a time, which shapes what a project here is: the network is the dataset, and tracking for the parcel numbers you supply is scoped as a job of its own.
The estate is large and it moves. Machines are installed, relocated and removed continuously as the network expands and sites change hands, at a rate no static export survives.
Attributes matter as much as locations. A locker with only small compartments cannot take a parcel that fits a medium, and a machine without card payment excludes cash on delivery. A map that ignores those sends customers to machines that cannot serve them.
Delivery: CSV, JSON or XLSX files, our API or a JSON feed. MCP server on request.
Full plan detailsMost location datasets tolerate age. A post office that moved six weeks ago is an annoyance. A parcel locker that was removed six weeks ago is a customer standing in a car park holding a phone, and a support ticket that costs more than the delivery.
The estate moves because the network is still expanding and because host sites change: a machine outside a shop that closed goes with it. The rate of change is high enough that annual or quarterly exports are not merely stale, they are actively misleading for a customer facing feature.
So the design is frequent collection with change detection, delivering additions, removals and relocations as records. Downstream that becomes an update rather than a full reload, which is both cheaper and safer: a reload that fails halfway leaves a checkout with a partial map, and a change feed does not.
The second reason is compartment size. A checkout that offers a locker which cannot physically accept the parcel produces a failed handover at the courier stage, and the customer experiences it as the retailer's mistake. Size attributes are what prevent that, and they have to be structured to be usable in a filter.
The third is coverage analysis, which is a different use entirely: where the network is dense, where it is thin, and how that maps against a retailer's customer base. That question is answerable from the estate alone and needs no tracking data at all.
Learn how to use web scraping to solve data problems for your organization
Leveraging advances in technology, the AI-powered web scraper has skyrocketed in demand and is helping to expand capabilities by automating tedious daily tasks and speeding up data collection from thousands of websites several times over.
Web scraping is a method of obtaining web data by extracting it from pages of web resources with the help of a program, that is, in automatic mode. It is used to syntactically convert web pages into more usable forms.
If you specialize in machine learning, you need to feed large amounts of data to the algorithms. Web scraping is the easiest and the most efficient method of collecting the data from all over the Internet.
ScrapeIt is a managed extraction company, not a tool you have to learn. Our team builds the pipeline, watches it as the estate and the page structure change, and repairs it before your checkout map drifts away from the street.
You see a sample first, in your format, for the areas you actually serve, with compartment sizes structured so you can test your checkout filter on real machines.
Still unsure? Write to info@scrapeit.io
Yes, for the parcel numbers you supply. The tracking surface answers one parcel number at a time, so it is a separate job from the locker network dataset, and we scope it separately rather than quoting both as one feed. Anti-bot handling on the tracking surface is part of the service.
Often enough that quarterly exports are misleading for anything customer facing. Machines are installed, relocated and removed continuously as the network expands and host sites change. A locker removed six weeks ago means a customer standing in a car park and a support ticket that costs more than the delivery.
Because a checkout that offers a machine which cannot physically take the parcel produces a failed handover, and the customer experiences that as the retailer's mistake. Sizes and their dimensional limits are delivered as structured fields so they can drive a filter, rather than as prose nobody can query.
Changes, for anything operational: additions, removals and relocations as their own records. Downstream that is an update rather than a full reload, which is cheaper and safer - a reload that fails halfway leaves a checkout with a partial map, and a change feed does not.
Yes, and for a retailer that is usually the more useful question. Several locker and pickup networks collected together give a picture of the delivery options actually available to your customers, rather than one network's view of itself.
You share your needs, expectations, and desired timeframe. We'll suggest the best solution based on your request and budget.
Our specialists configure the crawlers and extract a sample dataset for your review before proceeding with the full-scale extraction.
Once you approve the sample, we launch the project and start full data collection. We gather, filter, and structure the data for easy use, delivering it on time in your preferred format.
Our team manages ongoing processes, monitors website changes, and supports all data extraction cycles. We can also help integrate data into your systems or create dashboards to simplify analysis.
Tell us which sites, which fields and how often. A couple of lines is enough to start.
InPost data from €169/month. Free project assessment, reply within 1 business day.