Overview

Overview

What an Accelerator Is (and Isn't)

An accelerator is a pre-built, tested starting point that removes the blank-page problem. It is not a finished application, and it is not a substitute for discovery.

This one is narrower still: it is a schema. It creates 182 empty data models with their relationships wired. It does not fetch data, does not transform it, and does not present it. What it removes is the several weeks of modelling work between "we want Plex data in Fuuz" and "we have somewhere correct to put it."

Why an Accelerator, Not Off-the-Shelf

Plex exposes roughly 280 read contracts across a dozen API families. Modelling them by hand means:

• reading each schema and deciding a Fuuz type for every field;
• deciding which *Id columns are real references and which are attributes that merely look like one;
• declaring each relation from both ends, because a Fuuz relation is a pair;
• working out a load order in which no child is written before its parent.

Every one of those is mechanical, and every one is easy to get subtly wrong in a way that surfaces months later as a query that quietly returns nothing. Generating them from Plex's own dictionary makes the work repeatable and makes a vendor schema change a regeneration rather than an archaeology exercise.

How This Was Built

The models were not authored by hand and were not designed from a data dictionary someone wrote down. They were derived from Plex's own published API documentation, harvested from developers.plex.com.

The portal is a single-page app whose backing documentation JSON is public and unauthenticated, and it effectively serves the OpenAPI documents:

• one call returns the whole catalogue — 71 APIs, every operation;
• one call per operation returns it fully expanded — typed parameters, request body and response schemas, with Type, Format, Required, nested Properties and examples.

From that harvest — 283 read contracts across 71 APIs, resolving to 359 distinct response schemas, about 38 MB — a generator produces the Fuuz models: one model per distinct response schema, a Fuuz type per field, and a relation wherever a reference resolves to another modelled entity.

Three consequences worth understanding, because they explain most of this guide:

Coverage is a property of the generator. Nothing was selected by hand, so nothing was left out because it was tedious. The accelerator ships the whole read surface and lets the site enable what it needs.

Field-level fidelity comes from Plex, not from us. Types, formats and descriptions in these models are Plex's own. Where a field has no description, it is because Plex publishes none — 191 fields say so explicitly rather than restating their own name back at you.

The dictionary is dated, not versioned. Plex publishes continuously and stamps a last-modified per operation, so the honest version of a harvest is the day it was taken. Every row records the stamp it was generated from in sourceVersion.

This is derived from Plex's publicly published developer documentation. No Plex source material, database schema or proprietary artifact is included or redistributed — the models are Fuuz artifacts derived from a public API description.

---

The Vendor Dependency

This accelerator is a snapshot. Changes Plex makes to their API do not propagate to it.

There is no live link between developers.plex.com and an installed tenant. The models describe Plex as it was documented on 2026-08-05, and they will keep describing that until someone re-harvests and republishes.

See Versioning & Compatibility for what actually breaks, how each failure looks, and whose job it is to notice.

---

What Gets Installed

Master and transactional models	99
Sub-resource models	63
Analytics / report models	19
Configuration models	1

Coverage is every collection GET in the portal that resolves to a typed schema, plus the schemas reachable only through a single-entity GET.

Three Design Decisions Worth Knowing

The primary key is Plex's key. Every row carries externalId — Plex's own identifier, verbatim — and a create trigger copies it into id. This looks redundant and is the single most load-bearing decision in the package: the platform enforces a foreign key only when it targets id. Pointed anywhere else, a reference resolves when it can and silently returns null when it cannot. Making id the vendor key is what makes all 465 relations real rather than decorative, and it dedupes the source for free — the same record cannot land twice however many times it is read.

Every vendor field is nullable. A vendor's "required" flag describes their write contract, not what their read endpoint returns; optional modules, permissions and older records all produce absent fields. One NOT NULL on a field a given site does not populate fails an entire 500-row upsert batch. The only required columns are the two identity ones.

A reference with nothing behind it stays a plain string. Heat number, currency code, DUNS and tracking number look like foreign keys and are not — Plex exposes no endpoint for them, so there is no model to point at. 187 such fields remain strings. Inventing a model to satisfy a naming convention would be a lie the schema then tells every application that reads it.

What This Does Not Do

• It does not extract data. No connection, no credentials, no scheduled reads.
• It does not harmonise across sites. That belongs to the enterprise hub, which is a different package.
• It does not model Plex writes. This is a read mirror; Plex remains the system of record.