An aggregator is already the layer between you and the carrier. Adding a scraper on top of it stacks two delays and hides which one you are looking at.
ScrapeIt builds and runs the pipeline as a managed service. We integrate the official API, normalise statuses into your model while keeping the raw text at every level, record the three timestamps so latency is visible, and hand back CSV, JSON, Excel or a push into your warehouse.
Where the public pages are the right source - carrier coverage research, format discovery - we collect them at a civil rate. For tracking data we use the API, because it is what the service publishes for the purpose and because it survives redesigns.
Tracking data describes shipments with recipients at the end of them. We collect no recipient names and no address detail beyond the postcode level needed for lane analysis. Bring the use case to your own counsel before the project starts.
Tracking output carries the tracking number, the carrier the aggregator resolved it to, the raw status text as the aggregator words it, our normalised status, the event timestamp with time zone, the event location and the aggregator's own delivery state.
Two status columns exist for the same reason as on any carrier: the raw wording is what lets somebody audit a decision months later, and the normalised value is what lets a dashboard count anything. On an aggregator there is a third consideration, because the wording you see has already been translated once by the aggregator from the carrier's own vocabulary.
Latency fields are recorded explicitly and this is the part that distinguishes a careful pipeline from a careless one: when the carrier says the event happened, when the aggregator first showed it, and when we read it. Without those three you cannot tell a slow carrier from a slow aggregator from a slow schedule.
Carrier coverage records come from the published carrier list: carrier name, country, the identifier the aggregator uses and the tracking number formats it recognises. That is a useful dataset in its own right for anyone building a multi carrier product.
Every row carries the collection timestamp and the source, because a mixed pipeline that also talks to carriers directly needs to know which rows came from where.
The carrier coverage dataset is worth collecting on its own. Which carriers are supported, in which countries, and which tracking number formats are recognised is exactly the research a team does before choosing an aggregator, and it is published rather than inferred.
Mixed pipelines are the common end state. High value lanes go direct to the carrier where an integration exists, because the delay is shorter and the event detail is richer; the long tail goes through the aggregator because thirty integrations are not worth building. We design that split with the client and record the source on every row so the difference is visible.
Knowing when to go direct is part of the advice rather than an upsell. If most of your volume sits on three carriers, integrating those three directly and using an aggregator for the rest will beat any pure aggregator setup on both latency and detail. We will say so even though the direct integrations are more work for us.
Historical backfill is limited by what the aggregator retains, which varies by carrier and is worth checking before promising a client a year of history that does not exist.
17TRACK is a tracking aggregator: it connects to a very large number of carriers and postal operators and presents their events through one interface. A carrier coverage list is published and responds, and the service runs an official API on its own subdomain.
That structure is the first thing to understand, because it decides what the data can and cannot be. Every event you see here originated at a carrier, was collected by the aggregator, and is then served to you. Two hops, each with its own delay, and the second hop cannot be faster than the first.
Its crawl rules are unusually open - the robots file allows everything and publishes a sitemap - but that is not an argument for crawling it. The service publishes an API precisely so that automated clients use it, and the API is faster, structured and stable across redesigns.
So the honest framing is narrow: for coverage research and carrier discovery the public pages are fine, and for tracking data the API is the route. What we add is everything after retrieval, which is the part most teams underestimate.
Get a Quote
Developers
Customers worldwide
Pages extracted
Hours saved for our clients
€199 / one-time
setup fee - included
€169 / mo
setup fee €499
€229 / mo
setup fee €499
€349 / mo
setup fee €499
€549 / mo
setup fee €799
The appeal of an aggregator is obvious: one integration instead of thirty. The cost is equally real and usually unstated, which is that you are now looking at a copy of the carrier's data with an unknown delay in front of it.
For most reporting that is fine. For exception detection it is not, because the thing you are detecting is absence of events, and an aggregator delay looks exactly like a carrier gone quiet. A pipeline that cannot distinguish the two generates false alerts on the aggregator's schedule rather than on the shipment's reality.
So we record the three timestamps and report the gaps. Once you can see that a lane's events typically appear at the aggregator ninety minutes after the carrier timestamp, the silence threshold can be set against that rather than against a guess, and the false alerts stop.
The second issue is coverage honesty. An aggregator supporting a carrier and an aggregator supporting a carrier well are different things: some integrations return full event streams, others only a delivery state. We record what actually arrived per carrier rather than trusting a support matrix, and clients regularly find that two of their lanes are effectively unmonitored.
The third is the normalisation layer. The aggregator already mapped carrier wording into its own vocabulary; you then map that into yours. Each mapping loses detail, so we keep the raw text at every level and make the mapping explicit rather than burying it.
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 integration, watches it as carrier coverage and status wording change, and repairs it before your exception alerts start lying.
You see a sample first, in your format, on your own lanes, with the latency columns populated so you can see how far behind the aggregator actually runs before committing.
Because the aggregator gives you events, not a system. What we add is normalisation into your own status model with the raw text preserved, latency measurement so exception alerts fire on reality rather than on the aggregator's schedule, reconciliation against your orders, and delivery into your warehouse. If none of that is missing for you, you do not need us.
When the carrier says the event happened, when the aggregator first showed it, and when we read it. Without all three you cannot tell a slow carrier from a slow aggregator from a slow schedule, and exception detection based on silence will fire on aggregator delay. With them, the silence threshold is set against measured behaviour per lane.
Not uniformly, and a support matrix will not tell you. Some carrier integrations return a full event stream, others only a final delivery state. We record what actually arrives per carrier rather than what is claimed, and clients regularly discover two of their lanes are effectively unmonitored.
For the carriers carrying most of your volume, usually yes: shorter delay and richer event detail. For the long tail, no, because thirty integrations are not worth building. Most clients end up with a mixed pipeline, and we say so even though the direct integrations are more work for us.
Only as far as the aggregator retains, which varies by carrier and is worth checking before anyone promises a year of history. We check it for your carriers during scoping rather than discovering the gap after the project starts.
Step 1 - Make a Request
You share your needs, expectations, and desired timeframe. We’ll suggest the best solution based on your request and budget.
Step 2 - Configuring Custom Web Crawlers
Our specialists configure the crawlers and extract a sample dataset for your review before proceeding with the full-scale extraction.
Step 3 - Collect and Deliver
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.
Step 4 - Maintain and Support
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.
Scrapeit Sp. z o.o.
10/208 Legionowa str., 15-099, Bialystok, Poland
NIP: 5423457175
REGON: 523384582
