Sell Datasets Online: The VBWD Dataset Plugin, with an SEO Page per Dataset

Spread the love

Sell datasets as a catalogue on VBWD: a dataset is a Priceable, purchase grants an entitlement that unlocks API access, and each dataset gets its own indexable SEO landing page.

Selling data means gating access and being found; VBWD’s dataset plugin ties purchase to an API entitlement and gives every dataset its own crawlable page.

You have a dataset worth paying for. Maybe it’s cleaned air-quality readings across 400 cities, a decade of scraped price history, or a hand-labelled training corpus. The hard part was never the data. The hard part is turning it into something a stranger can find on Google, pay for, and pull down through an API without you emailing them a Dropbox link at midnight.

That is the gap the VBWD dataset plugin fills. It treats a dataset as a first-class product with its own price, its own access gate, and its own indexable page. This post walks through how the plugin works, how the purchase-to-access flow is wired, why each dataset gets its own SEO landing page, and where the honest limits are.

What the dataset plugin actually does

VBWD is a self-hosted, source-available platform: Python/Flask, PostgreSQL, Redis, and a Vue 3 / TypeScript frontend, all in Docker. The core is deliberately agnostic — it knows about users, pricing, and invoices, but nothing about datasets. All the domain knowledge lives in a plugin. You can see the broader plugin catalogue on the plugins page.

The dataset plugin introduces a “dataset” vertical. A dataset becomes a sellable entity you can list, price, and sell, without touching platform core code. Because it is a plugin, you enable it when you need it and leave it out when you don’t — the same way you would add a payment provider or a CMS block.

The Priceable to entitlement to API flow

The mechanism behind selling a dataset is three linked concepts. Understanding them tells you exactly what happens between “add to cart” and “curl the endpoint”.

Priceable. A dataset is a Priceable. It plugs into VBWD’s unified price model, so it carries a real price, currency, and tax treatment. When it goes into a checkout, invoices are generated with per-line tax, the same as any other product on the platform.
Entitlement. A completed purchase grants the buyer an entitlement to that specific dataset. The entitlement is the durable record that says “this user paid for this dataset.” It is not a download link and not a coupon — it is an access right stored server-side.
API access. The entitlement is what unlocks API access to the underlying data. When a request comes in, the plugin checks whether the caller holds a valid entitlement before serving a single row.

The piece that ties a payment to an access right is an invoice-line link registry. When an invoice line is settled, the registry maps that line back to the entitlement it should grant. This seam is why the flow stays decoupled: the checkout doesn’t need to know what a dataset is, and the dataset plugin doesn’t need to reimplement billing. Checkout itself runs through swappable payment plugins, so you can bill through whichever provider you already use. The billing model handles the money; the entitlement handles the access.

A page per dataset, built to be found

Selling online means being found online. A dataset buried three clicks deep behind a login will never rank. VBWD’s answer is per-entity SEO.

A plugin can attach SEO metadata — a page_seo record — to an individual entity. That means each dataset gets its own title, its own meta description, and its own social share image, served at its own URL. Ten datasets produce ten distinct, indexable landing pages, not one generic catalogue page that Google treats as a single result.

There is a well-known problem with single-page Vue apps: crawlers often see an empty shell instead of rendered content. VBWD solves this with an SEO renderer sidecar that serves crawlable HTML for those SPA pages. The upshot is that each dataset’s landing page can actually be indexed and ranked, rather than showing up as a blank page to a bot. The features overview covers how the SEO rendering path fits with the rest of the platform.

The listing side uses the shared catalogue contract — an agnostic filter-and-pagination seam — so browsers can narrow a large collection by facets you define, while the CMS supplies the surrounding pages (a landing page, an about page, terms of use). You get a browsable storefront and a dedicated page per item from the same building blocks.

A worked example

Say you sell hourly air-quality data. Here is the shape of the flow end to end.

First, you register each city’s dataset as a Priceable with a price and a description. The plugin exposes it in the catalogue, and the SEO metadata gives it a page:

Dataset:      air-quality-berlin
Price:        one-time, unified price model, tax per line
SEO page:     /datasets/air-quality-berlin
  title:        "Berlin Air Quality Dataset - Hourly PM2.5, 2015-2025"
  description:  "10 years of hourly PM2.5, NO2 and O3 readings for Berlin..."
  social image: og-air-quality-berlin.png

A buyer lands on that page from search, sees the sample and the price, and checks out. The invoice is created with per-line tax; the payment runs through your configured payment plugin. On settlement, the invoice-line link registry grants the entitlement:

Purchase settled
  -> invoice line "air-quality-berlin"
  -> registry maps line to entitlement
  -> user now holds entitlement: air-quality-berlin

Now the buyer calls your data API. The plugin verifies the entitlement before returning rows:

GET /api/v1/datasets/air-quality-berlin/records?from=2024-01-01
Authorization: Bearer <user token>

# plugin checks: does this user hold an entitlement
# for air-quality-berlin? yes -> 200 + data
#                          no  -> 402 / 403, no rows leaked

No manual file hand-off, no shared links to leak, and every sale is a real invoice in your books. Add a new city and you have added a new product and a new page that can rank on its own. Implementation specifics for wiring the endpoints and metadata live in the documentation.

The honest limits

This is a tool, not magic, so it is worth being clear about what it does not do for you.

You host the data and own its licensing and quality. Because VBWD is self-hosted, the dataset sits on your infrastructure. Whether you have the right to sell it, whether it is accurate, and whether it is kept current is your responsibility, not the platform’s.
The entitlement gates access; you design the API. The plugin decides whether a caller is allowed in. What the endpoint returns, how it is paginated, and what rate limits apply are yours to design. A paid entitlement does not stop someone from hammering an unthrottled endpoint — that is an API design choice you still have to make.
A page is not a ranking. Per-entity SEO gives every dataset a crawlable, well-formed page. It does not guarantee position one. Ranking still depends on genuinely useful content, a description worth reading, and demand for the data. The plugin removes the technical blockers to being indexed; it does not write your copy or create the demand.

There is also the licensing frame to keep in mind: VBWD ships under BSL 1.1, free to use until you cross roughly 6.7 BTC in attributable annual sales, after which a commercial arrangement applies, and the licence converts to Apache-2.0 on schedule. For most people getting started with dataset sales, that ceiling is far away.

Takeaway

Selling datasets online usually breaks in the boring places: payment plumbing, access control that leaks, and pages no search engine ever sees. The VBWD dataset plugin addresses all three with one coherent flow — a dataset is a Priceable, a purchase grants an entitlement, and the entitlement gates the API, while each dataset carries its own indexable page so buyers can find it in the first place.

You still own the data, its licensing, and the quality of both your API and your content. But the infrastructure between “I have a dataset” and “someone paid for it and pulled it down cleanly” is already built, self-hosted, and yours to run.