Origins

Browser calls to the Onboard API check allowedOrigins on the published flow config (config, progress, and outcomes). Default * helps first run. Live Hosted should list exact origins (localhost plus production). A disallowed Origin receives HTTP 403. Calls without an Origin header (server-side fetch, curl) are not blocked by this check. The service also honors a deployment-level CORS_ORIGINS setting for Access-Control headers.

This limits which browser origins can call public Onboard endpoints from a web page. It is an HTTP browser control, not an application authorization system.

What origins do not replace

  • Secret keys. Keep bsw_*_sec_ off the client. Origins do not make a leaked secret safe.
  • Host-asserted identity. Publishable key + user.id can be forged if the key leaks. Restrict who can load your embed and treat user.id / workspaceKey as trust boundaries. See Identity.
  • BYO authz. If you pass an OnboardAdapter, your API must authorize writes from your session. CORS on Bootstrapware does not protect your backend.

Practical guidance

  • Set allowedOrigins on the flow draft via MCP or the dashboard. Prefer explicit production origins over *. List localhost and production before live.
  • Use test publishable keys (bsw_test_pub_) while iterating; switch live keys when customers hit the embed.
  • Optional apiBaseUrl on the component defaults to https://onboard.bootstrapware.co. Point local embeds at your deployed Onboard service only when you intend to.

Related: API keys · Identity · Environments · Security