What an application is
A Plexara Application is one record naming everything a system built in Plexara is made of, released together as one pinned set. The PBS SoCal MCP (Plexara) builds all of it by asking, the same way it builds a site.
Site
The pages people open: dev, stage and prod, at any domain.
Endpoints
Small scripts that answer /endpoints/<name> as the signed-in person.
Database
A PostgreSQL schema of the application's own, plus the Data Estate behind it.
How a page calls it
Once a site environment is part of an application, that environment's addresses also answer the application's endpoints. A page calls them on its own address, with an ordinary fetch. There is no API key in the page, no separate server and no cross-site setup:
// On hello.pmgsc-data.org, or any address of an environment in the application
const res = await fetch("/endpoints/pages-demo/schedule?day=2026-11-20");
const day = await res.json(); // the airings, answered from the application's databaseThe platform passes along who is signed in, so the endpoint knows the person and runs with their access. Only requests the browser marks as coming from the site itself carry that identity, so another website can't use your session to call it.
The parts
| Part | What it does | In the examples |
|---|---|---|
| Site environments | The pages. A site's dev and prod can both be parts, so each serves the endpoints. | hello/dev, hello/prod |
| Database schema | Tables, rules and permissions, built by versioned migrations that a release applies. | pages_demo: airings, snapshots, suggestions |
| Endpoint scripts | The application's API. Each request runs a small script that reads or writes the database or the Data Estate. | pages-demo-api |
| Scheduled scripts | Work on a timer: copy data in, compute summaries, send reminders. | pages-demo-sync, every three hours |
| Forms | A form the platform validates, protects from bots and stores, then hands to a script. | The suggestion form posts to the endpoint |
| Event sources | Webhooks or database changes that start a script once per event. | Not used here |
| Portal assets | Dashboards and reports in the PBS SoCal portal that belong to the application. | Not used here |
Application security
- Runs as the viewer. An endpoint called from a private environment runs as the person signed in. What it can reach is what that person, and the application, may reach.
- Its own database role. An application's scripts sign in to the database as a role made for that application alone, with no superuser rights. Another application's script can't read its tables.
- Rows that belong to people. The database knows who each request is for, so a table can show each person only their own rows. The suggestion example does exactly that: you see your suggestions, and the tally shows counts but never who sent what.
- Identity from the session, never the page. The suggestion form doesn't send your email. The database takes it from the sign-in, so nobody can submit as someone else.
- Checked input. Endpoints check what they're sent; forms are validated by the platform before a script sees them, with limits on size and rate.
- Every change reviewed. Scripts are saved only with passing tests, and the database changes only through migrations. Nothing goes live until a release.
Releases
Saving a script or adding a migration changes nothing people use. A release applies the pending migrations and pins each script's version and each site environment's release together, so the pages and the API they call always match. If a migration fails, the release changes nothing. A rollback restores the previous release's versions in one step.
Releasing an application moves its site environments one step, the same as a promote: prod takes the release dev serves. So review dev before you release.
Public applications
An application's site can be public at its own domain, for visitors with no PBS SoCal account. Its endpoints are then bound as public or bot-checked instead of signed-in, and an administrator approves each version before the public reaches it. A public form can be framed by the application's own sites. Anything only staff should see stays on a private environment.