Using the FTVDB API for Automated Submissions

If you capture update URLs regularly, manual submission gets repetitive.

The FTVDB API exists so you can send newly found URLs directly from your own tools. That is useful if you are reading device logs, parsing captured traffic, or running scripts that extract update links from a larger workflow.

The endpoint

FTVDB currently supports two simple ways to submit a URL:

GET https://api.ftvdb.com/submit-url?url=ENCODED_URL

or

POST https://api.ftvdb.com/submit-url

with JSON:

{ "url": "https://example.com/update.bin" }

Both methods return JSON with two fields:

• error
• message

That makes it easy to integrate into shell scripts and small tools without needing a heavy client library.

Quick shell examples

If you already have a URL in hand, a GET request is the fastest option:

curl "https://api.ftvdb.com/submit-url?url=https%3A%2F%2Fexample.com%2Fupdate.bin"

If your tool already produces JSON, POST is usually cleaner:

curl -X POST "https://api.ftvdb.com/submit-url" \
  -H "Content-Type: application/json" \
  -d '{ "url": "https://example.com/update.bin" }'

Submitting from a script

Here is a small Bash example that submits every captured URL from a text file:

while IFS= read -r url; do
  [ -n "$url" ] || continue
  curl -s -X POST "https://api.ftvdb.com/submit-url" \
    -H "Content-Type: application/json" \
    -d "{\"url\":\"$url\"}"
  echo
done < urls.txt

That kind of workflow is useful if you export URLs from adb logcat, network captures, or device logs and want to hand them off to FTVDB in one pass.

What to automate and what not to automate

Automation works best when your script is only sending URLs that were actually captured from real device activity.

I would avoid sending guessed URLs, generated paths, or bulk lists that have not been verified against a device log. FTVDB is most useful when the submissions reflect real public update links that somebody actually observed.

That is also why not every submitted URL will necessarily end up in the public database. Submissions are reviewed, checked, and organized before they appear on the site.

A practical workflow

A simple setup can look like this:

1. Capture update URLs from a device log.
2. Extract only the URLs.
3. Remove duplicates locally.
4. Submit each URL through the API.
5. Keep your original logs in case a record needs clarification later.

That workflow keeps the public database cleaner and saves time if you capture links often.

Why this matters

One of the goals of FTVDB is to make contribution easy enough that useful links do not get lost just because somebody did not have time to submit them by hand.

If you already collect logs or build your own research tools, the API gives you a straightforward way to feed that work into the database.

If you build something on top of it, I would be interested to hear about it.