People often assume that once public data is available, the hard part is over. Publish an API, release a bulk download, put PDFs on a website—problem solved.

While building infrastructure for integrating trademark data from national and international trademark offices, we encountered a recurring pattern that felt surprisingly familiar to anyone who has worked in Internet infrastructure: making public data available and making it reliably consumable are fundamentally different problems.

Readers in the domain industry will recognise this immediately. Anyone who has worked with WHOIS, RDAP, zone file access, or registry-specific EPP extensions knows the feeling: dozens of independent operators publishing nominally similar data, each with its own authentication scheme, rate limits, formats, and operational quirks. Trademark offices tell much the same story in a completely different ecosystem.

Same data, wildly different plumbing

Trademark offices around the world publish remarkably similar information. Applications, registrations, status changes, ownership updates, renewals, and cancellations exist everywhere. The challenge is not what is published, but how it is published.

Some offices provide modern REST APIs. Others expose SOAP services. Some distribute bulk datasets via FTP or rsync, while others publish only official gazettes as PDF files. Authentication ranges from API keys and OAuth to manually issued JWT tokens, SSH tunnels, and contractual onboarding processes. In several cases, there is no machine-readable interface at all. The result is that integrating one trademark office tells you almost nothing about integrating the next.

One of the more surprising discoveries was that some of our most reliable data sources were also the oldest. Official gazettes, despite their age and often inconvenient PDF format, turned out to be one of the few publication mechanisms shared by almost every jurisdiction. They are legally significant, publicly accessible, and relatively stable over time. They are considerably harder to process than an API—but far more universally available.

When plausible assumptions meet operational reality

Data quality proved equally unpredictable. One weekly bulk archive arrived with a perfectly valid content length, yet the ZIP file itself was corrupted. Another office accidentally published filing dates decades into the future because of a simple data-entry error. And in one memorable case, millions of records became effectively invisible because a processing pipeline derived partition dates from temporary filenames instead of the records themselves—filing them all under the year zero.

None of these failures were software bugs in the traditional sense. They were perfectly plausible assumptions meeting imperfect operational reality.

Failure is not the exception—it is the design

The most important lesson was that failure itself had to become part of the system design.

Network interruptions happen. APIs time out. FTP servers disconnect. Data providers publish incomplete files. Authentication tokens expire. Infrastructure is redeployed while downloads are still running. Treating these situations as exceptional conditions quickly leads to brittle systems—every incident becomes a fire drill, and every fire drill erodes trust in the data.

The alternative is to design for convergence rather than correctness on the first attempt.

Ingestion pipelines assume that transient failures are normal. Work resumes from durable checkpoints instead of starting over. Failed downloads converge toward completion across retries. Retry logic distinguishes between permanent and temporary failures. The system’s job is not to execute a perfect run; it is to continuously reconcile itself with external sources that change, break, and recover on their own schedule.

Once you adopt that framing, engineering effort shifts noticeably. We expected parsing to be the hard part. It rarely was. The real work is building a system that is always slightly wrong and always converging—much like many other distributed systems on the Internet.

The hardest problems were not technical

Interestingly, many of the hardest problems were not technical at all. Obtaining access credentials often required email exchanges, contractual agreements, or manual approval processes. Documentation became as important as source code because interfaces are operated by organisations rather than by software alone. Every trademark office represented its own operational environment, release process, and institutional history.

In retrospect, the challenge was never integrating another API. It was building infrastructure capable of accommodating dozens of independent organisations, each evolving at its own pace, with its own priorities and technical assumptions.

Why this matters for Internet infrastructure

Trademark data increasingly influences the domain name ecosystem. Domain registrations, brand protection, abuse investigations, dispute resolution, and registrar workflows all depend, directly or indirectly, on reliable trademark information. Yet the infrastructure for consuming this data has received far less attention than protocols such as RDAP or EPP.

What publishers of public data could do

The experience also suggests what would actually help. Institutions that publish public data—trademark offices, registries, or anyone else—do not need to converge on a single perfect API. What consumers need is more modest: stable, documented formats that change with notice rather than silently; checksums or manifests alongside bulk files, so corruption is detectable before it propagates; changelogs and status pages, so consumers can distinguish “the data changed” from “something broke”; and access processes that do not depend on knowing the right person to email. None of this is glamorous. All of it is the difference between data that is technically public and data that is practically usable.

Public data is valuable. Public infrastructure deserves at least as much engineering attention as the public data it exposes.

The observations in this article emerged while building the data integration layer behind MarkMesh, a trademark data platform.