Bridge Payments Docs

Appearance

Module Hub & platform extensions ​

Bridge Payments ships with more than REST payment routes: you can install database modules (plugins), and optionally expose hosted UI surfaces for checkout and billing.

Module Hub (admin plugins installer) ​

On each Bridge instance, installable SQL modules are loaded from the application’s modules/ directory (native manifests) and optionally from legacy plugin manifests under database/plugins/. Your deployment includes whatever modules your build ships with; you do not need a separate private documentation URL to use the installer.

Discover what is available on a running instance:

  1. GET /bridge-payment/admin/plugins/status — hub tables present?
  2. GET /bridge-payment/admin/plugins — modules discovered from disk plus registry summary.

Full installer contract (methods, paths, bodies, responses, operationId values): API Reference → group Admin - Module Hub (OpenAPI-driven operation pages).

The Module Hub follows the same pattern as Flowless: SQL described in manifests installs into module_hub_registry / module_hub_events.

WhatDescription
PurposeBootstrap tables, then install or upgrade SQL components per module
Manifestsmodules/<module_id>/manifest.json (native) or database/plugins/<plugin_id>/plugin.json (legacy)
DialectsSQL paths can use {dialect} for postgresql, mysql, sqlite
API prefix/bridge-payment/admin/plugins (requires admin session)
DocsAPI Reference — Admin - Module Hub

Typical flow:

  1. GET /bridge-payment/admin/plugins/status — confirm hub tables exist (or bootstrap first).
  2. POST /bridge-payment/admin/plugins/run — create hub tables when needed.
  3. GET /bridge-payment/admin/plugins — list modules discovered on disk.
  4. POST /bridge-payment/admin/plugins/:module_id/dry-run then .../run — apply SQL.

Managed deployments

On Pubflow-managed instances, module installation is usually operated by your team or support; the API exists for parity with Flowless-style workflows.

Bridge Pages (/pages/*) ​

Server-rendered HTML flows (pay links, billing dashboard, account areas) are mounted at /pages/* on your Bridge host when enabled (not under /bridge-payment).

FlagEffect
PAGES_ENABLEDWhen true, mounts hosted pages.

Use this when you want shareable URLs or minimal frontend work while still using Flowless sessions.

Bridge Embeds (/embed/*) ​

Embeddable widgets are mounted at /embed/* when enabled.

FlagEffect
EMBED_ENABLEDWhen true, mounts embed routes independently of pages.

Independent toggles

PAGES_ENABLED and EMBED_ENABLED are separate. You can enable only pages, only embeds, both, or neither.

Other optional feature routes ​

When the corresponding environment flags are on, Bridge exposes additional JSON routes (prefix /bridge-payment/ unless noted). Configure flags in Environment Setup.

AreaMount prefix (when enabled)On this site
Projects/bridge-payment/projectsPublic invite lookup GET .../invites/:token is rate-limited. Related: Organizations guide.
Memberships/bridge-payment/memberships and /bridge-payment/admin/membershipsMemberships API
Cost tracking/bridge-payment/cost-trackingEnvironment Setup (COST_TRACKING_ENABLED)
Billing schedules/bridge-payment/billing-schedulesEnvironment Setup (BILLING_SCHEDULES_ENABLED)
Receipts/bridge-payment/receiptsEnvironment Setup (INVOICES_RECEIPTS_ENABLED)
Invoices/bridge-payment/invoicesSame flag as receipts

API Reference

Each HTTP route above is also documented as an OpenAPI operation (its own page under API Reference), grouped by tag—for example Bridge Pages, Bridge Embeds, Projects, Memberships, Cost Tracking, Billing Schedules, Invoices, and Receipts—the same pattern as Admin - Module Hub.

Where this fits in architecture ​

Modules extend the database layer (schema, registry, events). Pages and embeds are HTTP UI surfaces on the same Bridge instance as the JSON API—they reuse the same auth and provider stack described in Architecture.

Next steps ​