I Built a Documentation Tool Because a Copyright Claim Had No Paper Trail
TrackDataPad didn’t start as an edge micro-SaaS idea. It started with a blown sugar video.
I was editing footage of a chef shaping molten isomalt — delicate, glass-like structures bending under heat. I found a track on Pixabay labeled “no copyright,” uploaded the video, and it got flagged.
If the track was covered by the Pixabay license, what exactly was going on? A quick search confirmed I should dispute the claim. I went looking for the certificate Pixabay provides at download, but couldn’t find it on my hard drive. Going back to the track page to download it again, I hit another wall — no certificate available.
That sent me down a rabbit hole. I learned that Pixabay distinguishes between Content ID and non-Content ID tracks. Content ID tracks get a shield icon and a downloadable certificate you can submit with YouTube disputes. Non-Content ID tracks have neither. Claims can still come in on them — through third-party registrations or automated detection — but when they do, disputes are handled manually using the standard Pixabay license instead of a pre-generated certificate.
So what was I supposed to paste into the dispute field?
When you open the YouTube Studio dispute form, it wants structured information: track title, artist, source URL, license type, confirmation of where you downloaded it. None of that is hard to find. What’s hard is that Pixabay doesn’t give you a license certificate for non-Content ID tracks. You downloaded a file. That’s it. Now reconstruct the paper trail from memory, under mild panic, and translate it into a coherent dispute statement.
The problem wasn’t legality. The license was valid. The problem was structure.
Each platform functions correctly in isolation.
The failure emerges at the boundary between systems.
Each platform functions correctly in isolation.
The failure emerges at the boundary between systems.
So I built TrackDataPad to save other creators from having to learn the non-Content ID system the hard way — the way I, and plenty of others, had to.
The Actual Problem
The workflow between “I have a valid Pixabay license” and “I can submit a coherent YouTube dispute” was entirely manual and unstructured.
TrackDataPad formalizes that gap. You paste a Pixabay track URL. The system scrapes canonical metadata — title, artist, username, file ID, URL — detects Content ID participation status, and generates a plain-text documentation record formatted for dispute workflows. For non-Content ID tracks only. That’s the whole product. Deterministic input-to-output.
Architecture Decisions (And Why)
The stack is deliberately minimal:
- Cloudflare Pages — static frontend
- Cloudflare Workers — stateless API layer
- Cloudflare KV — license state and usage counters
- Stripe — billing via webhook
The Worker handles everything: license validation, daily cap enforcement, metadata structuring, abuse mitigation, and Stripe webhook processing. Single file, covered by a Vitest suite.
Runtime Architecture
User
│
▼
Cloudflare Pages (Static Frontend)
│ (fetch)
▼
Cloudflare Worker API
│
├── Cloudflare KV (usage counters, license state)
└── Stripe Webhook (subscription activation)
Why edge-native? The system generates documentation adjacent to copyright workflows. Long-lived tokens, session state, and overcollection of user data are all unnecessary risks. Stateless compute at the edge keeps the operational surface small and the architecture honest.
Why KV instead of a database? This is a micro-SaaS. License records, usage counters, and audit logs don’t need relational queries. KV is sufficient, affordable, and has fewer failure modes.
Abuse Prevention Is Infrastructure, Not Policy
If you expose a metadata generation API publicly, people will try to scrape it. That’s not a security failure — it’s just the internet.
So from the start, the free tier uses three-layer tracking:
- Composite identifier (IP + browser fingerprint + device ID)
- Browser fingerprint only (persists through cookie clearing via IndexedDB)
- IP-based cap (covers shared networks, with a higher threshold)
Daily TTL-bound counters in KV. If any layer hits its limit, the request is denied.
The app is free, with 3 records per day. Once the Chrome extension ships, there’ll also be a pro version with batch mode for regular uploaders, multi-video managers, or anyone who wants to back the project.
The Chrome Extension Delay (And What I Did About It)
I was hoping to launch the web app and extension together, but the Chrome Web Store review is taking longer than expected. They need proof of residence on the developer profile before approval — that’s what’s holding things up.
The extension was the primary way users could autofill track metadata directly from a Pixabay page — title, artist, licensee, file ID pulled from the live DOM without manual copy-paste.
Rather than wait with nothing to ship, I built a bookmarklet that requires no install and works the same way. The extension and bookmarklet share the same scraping logic and produce identical output.
When the extension clears review, the bookmarklet stays as a fallback.
The Systems Lesson
This project exists because three systems don’t communicate: Pixabay (asset distribution), YouTube non-Content ID (automated detection), and YouTube Studio (human dispute workflow).
Each one functions correctly in isolation. The friction emerges at the boundaries.
TrackDataPad doesn’t solve copyright. It doesn’t override Content ID or interfere with YouTube. It simply restores structure at the boundary between systems.
The blown sugar video eventually cleared. No strike, no penalty.
But the more useful outcome was understanding the system well enough to reduce uncertainty the next time — and to build something that reduces it for other creators too.
TrackDataPad is live at https://trackdatapad.com