Skip to main content

Integration platforms

Master catalog of customer integrations Brandblox supports or plans to support. Use Integrations for connect / export how-tos and the public capability matrix. Filter chips in-app (and on the marketing Integrations page) use capability tags: Email Export, Content Generation, Asset Generation, Automations, Asset Storage. A provider can carry more than one tag (for example OpenAI is both Content Generation and Asset Generation). Pricing is the vendor’s public entry model (as of 2026-10), not Brandblox billing. Values: Free · Free+paid · Free+trial · Trial-only · Paid (sales-led). Priority is Brandblox build order for Emails (and similar) connectors — separate from Status: Status reflects Brandblox main (app catalog + integrations Worker vault), not Bubble-era leftovers. A platform can be Built with Priority On hold when it shipped despite sales-led pricing (e.g. Braze). Highest can also be a product override for a paid plan (e.g. Vero).

Public support matrix (shared)

Customer-facing capability columns live in one Mintlify snippet so Integrations and this page stay identical. Only Built providers appear here — Planned / On hold stay in the catalog tables below. Legend: Yes = shipped capability for connected orgs · Partial = connectable but limited (see notes) · — = not this provider’s job Partial notes (code-backed):
  • Asset Generation (OpenAI / Claude / OpenRouter) — Generate UI unlocks with an enabled AI integration; image output today is a placeholder stub, not a full vaulted image model call.
  • Asset Storage (S3) — BYO bucket settings connect in Integrations; credentials are not vaulted yet, so uploads stay on Brandblox R2 until that slice ships.

Keeping docs in sync

When you add or change a Built customer provider:
  1. Ship code first (ALL_PROVIDERS / PROVIDER_CATEGORIES / EMAIL_EXPORT_PROVIDERS / AI_PROVIDERS in src/lib/integration-config.ts + src/lib/ai-integrations.ts, and vault allowlist in the integrations Worker).
  2. Update help/snippets/integrations-support-matrix.mdx (Yes / Partial / — only for capabilities that work in code).
  3. Update Platform / Area / Pricing / Priority / Status / Notes rows in the tables below (include Planned / On hold here; omit them from the public matrix until Built).
  4. Refresh connect / export copy on Integrations if Connect fields or export ops changed.
Do not mark Yes for aspirational features. Partial needs a short note in the snippet. Emails API capabilities (build guide): Notes below summarise what each vendor’s public API documents (template, campaign, asset upload, content blocks, lists, send/schedule, preview/test). Feature bullets on the www Integrations page and EMAIL_PROVIDER_API_CAPABILITIES in src/lib/email-provider-capabilities.ts must stay aligned. Shipped Brandblox export today is still template/campaign (+ lists) for Built rows — deeper API ops are the next build targets, not “(planned)” labels on bullets.

Customer vault (org-owned keys)

Customer API keys live in the integrations Worker vault (AES-GCM in D1). Neon stores only connection metadata (name, provider, vault secret_id, last-four hint, non-secret config). Brandblox never calls ESP/AI REST with raw keys from the app Worker. Deep links for built Emails connectors: Klaviyo, Braze, Mailchimp, Brevo, Omnisend, HubSpot, Kit, MailerLite, SendGrid, Mailjet, Vero, Bird.

Platform-owned (not customer vault)

These power Brandblox itself. They do not appear as customer Add Integration rows (except BYO S3, which is customer vault metadata above). Priority does not apply (not in the customer Emails build queue).

Not a customer integration

Ownership rules (summary)

Engineering vault notes: repo docs/integrations-vault.md. Placement / Worker roles: Project store docs/integrations-placement.md.

Status legend