How it works
A sandbox with a bridge.
Apps talk to WordPress through a typed, permissioned API. In iframe mode they also get a browser sandbox boundary. In inline mode they become real crawlable pages with CSP and sanitization. Below: the runtime, the bridge, the permissions, and the WordPress APIs DSGo sits on top of.
The bundle → install → runtime flow
From a static bundle to a live, data-aware page.
Bundle
A static directory with HTML, JS, CSS, and a dsgo-app.json manifest. Authored by AI in your browser, by Claude Code locally, or hand-written.
Install
Validated and extracted into the site. The admin sees the app’s requested capabilities, rendering mode, and network policy before approving the install.
Runtime
Served at /apps/{slug}, embedded as a Gutenberg block, or promoted to your site’s home page at /. The bridge handles auth and REST behind the scenes; the app calls dsgo.posts.list().
Two isolation modes
Inline for crawlable pages. Iframe for drop-in artifacts.
Same bundle format, same bridge — different rendering. Apps declare which they want in the manifest; the runtime picks up the rest.
Inline mode
App renders as a real WordPress page with strict per-request CSP, install-time and render-time HTML sanitization, multi-page routes via the manifest’s routes array, optional theme header/footer wrap, and automatic sitemap inclusion. Crawlable, indexable, fast.
"isolation": "inline" Iframe mode
App renders inside a <iframe sandbox="allow-scripts"> with an opaque origin. Single-page, not crawlable, but ideal for drop-in artifacts (like a saved Claude page) and for apps that want the strongest isolation guarantee.
"isolation": "iframe" The bridge
A typed window into your WordPress site.
Apps never see a REST token. The parent calls REST on their behalf with permission checks in one place. Same wire format whether the app is in an iframe or running inline.
v1 bridge methods
Read-first by design, with a few deliberate exceptions: storage is built in, commerce includes cart/checkout operations, and additive v1.x methods cover abilities, email, and AI. Apps never receive a REST token.
| Method | Returns | Permission |
|---|---|---|
| dsgo.site.info() | Site name, URL, language, timezone | site_info |
| dsgo.posts.list(query) | Posts (filtered by current user’s caps) | posts |
| dsgo.posts.get(id) | A single post | posts |
| dsgo.pages.list(query) | Pages | pages |
| dsgo.pages.get(id) | A single page | pages |
| dsgo.user.current() | Logged-in user or null | user |
| dsgo.user.can(cap) | boolean | user |
| dsgo.storage.app.get/set | Per-app shared state | none |
| dsgo.storage.user.get/set | Per-app, per-user state | none |
| dsgo.abilities.list() | Abilities other plugins registered | abilities |
| dsgo.abilities.invoke(name, args) | Ability result | abilities |
| dsgo.ai.prompt(messages) | LLM response via the site’s Connector | ai |
Permissions
Browser-extension-style consent — in plain English.
The manifest declares what the app needs. The site admin sees the bridge permissions, rendering mode, and network policy before approving the install.
recipe-leaderboard wants to:
The stack underneath
Built on WordPress APIs, with AI features on 7.0+.
DSGo is an orchestration layer on top of WordPress core APIs. The site admin configures keys once at Settings → Connectors; every DSGo app inherits. We never hold credentials. We never pay for inference.
Connectors API
WP 7.0. Site admin configures Anthropic / OpenAI / Google credentials once. Every plugin using WP AI Client inherits.
WP AI Client
WP 7.0. Provider-agnostic PHP API. Plugins call wp_ai_client_prompt(); the user’s Connector handles the call.
Abilities API
WP 6.9 + 7.0. wp_register_ability() exposes AI-callable functions. DSGo apps can both invoke them and publish their own.
See the bridge in real code.
The CLI scaffolds a starter Astro app with the typed bridge wired up and a CLAUDE.md documenting every method.