§ 01 — INVESTOR PORTALS

Pre-built connectors. For the portals sponsors actually use.

Connectors push verification links and receipt PDFs into the portal's investor view at subscription, and surface the live verify endpoint as an embedded widget. You can also verify transaction records directly on the verification page, and review system safeguards under platform security standards. Status indicates production-readiness; "Beta" connectors have working integrations but limited reference customers.

Connector 01 · Portal

InvestNext

Push transaction codes and receipt PDFs into the investor portfolio view at close. Embed the verify widget on the subscription confirmation page.

● ProductionWebhook + widget
Connector 02 · Portal

Juniper Square

Attach the FBC custody record to each investor's subscription record. Custody URL surfaced on the investor dashboard's documents tab.

● BetaAPI + widget
Connector 03 · Portal

Carta

For Carta-managed SPVs, surface the verification code in the investor's Carta documents tab and provide a deep-link to /verify with the code prefilled.

● BetaAPI
Connector 04 · Portal

Allocations

Embed the FBC verify widget inside the Allocations-hosted investor view. Receipt PDF available from within the SPV detail page.

● ProductionWidget
Connector 05 · Portal

Sydecar

FBC custody disclosed on the Sydecar deal page; transaction codes delivered with the subscription confirmation.

● On requestAPI
Connector 06 · Portal

Vauban & Roundtable

European-domiciled SPV platforms. FBC connector surfaces custody records to EU-resident investors with appropriate jurisdictional disclosures.

● On requestAPI
Connector 07 · Accounting

QuickBooks Online

Vendor connector to feed FBC invoicing into sponsor accounting. Memos include SPV and custody-record references for clean reconciliation.

● ProductionOAuth · billing
Connector 08 · Accounting

Xero

Same as the QuickBooks connector — sponsor-side invoicing flowed into Xero with custody-record metadata.

● ProductionOAuth · billing
Connector 09 · Identity

Okta / WorkOS / Google SSO

Dashboard access via the sponsor's existing identity provider. SAML, OIDC, and SCIM provisioning supported on Tier 02 and above.

● ProductionSAML · OIDC · SCIM
§ 02 — ENGINEERING SURFACE

Three primitives. Build anything against them.

Whatever portal or workflow you run, the engineering primitives below cover the integration. Most sponsors at Tier 02 are using the widget + webhook combination; engineers integrating from scratch use the REST API directly. Full technical context is documented in How the system works, and commercial onboarding details are available under Pricing plans.

Surface 01 · HTTP

REST API. Read-mostly. Rate-limited.

Three endpoints — ingest, verify, receipt. Ingestion requires authenticated HMAC; verify and receipt are public and rate-limited. JSON in, JSON out, semantically versioned with 12-month deprecation notice.

  • Basehttps://fundbasecamp.com/api/v1
  • AuthBearer + HMAC · ingest only
  • Formatapplication/json
  • Versioningv1 · semver · 12-mo deprecation
Read API docs
Surface 02 · Browser

JS verify widget. Embeds in your portal.

Drop-in widget that renders the verify endpoint inside a sponsor portal. No iframe, no data leaves the sponsor domain except the verification code. CSP-safe, zero dependencies, branded to the sponsor's style tokens.

  • Script/embed/verify.js
  • Size≈ 8 KB gzipped
  • DependenciesNone
  • CSPSafe · no inline scripts
Get widget docs
Surface 03 · Push

Webhooks. Anchor state, signed.

Outbound HTTP calls when material state changes in custody — primarily anchor.finalized when a deposit's Bitcoin anchor reaches ≥3 confirmations. Signed with HMAC-SHA256, retried with exponential backoff.

  • Eventsanchor.finalized · attestation.published
  • SigningHMAC-SHA256 · timestamped header
  • Retries3× · exponential backoff
  • ReplayIdempotent · event_id included
Webhook reference
Surface 04 · Server-to-server

JSON over HTTPS. For your back office.

For sponsors running their own admin software, the same verify endpoint can be called server-to-server. No special API; identical to the public endpoint, just with optional User-Agent identification for support routing.

  • EndpointSame as public verify
  • AuthNone required
  • Rate limitElevated · whitelisted IPs
  • Responseapplication/json
Endpoint spec
§ 03 — WIDGET · EXAMPLE

Drop-in widget code. Two lines.

The standard widget integration. The script tag and a target element; everything else is rendered by FBC on your domain. Style tokens override the defaults — match your portal's colors and fonts.

HTML · sponsor portal · subscription confirmation page copy & paste
<!-- 1. Load the widget (defer recommended) -->
<script src="https://fundbasecamp.com/embed/verify.js" defer></script>

<!-- 2. Drop a target wherever the verify UI should appear -->
<div data-fbc-verify
     data-code="FBC-26A-INV-0042"
     data-theme="light"
     data-accent="#0D6B4F"
     data-font="'IBM Plex Sans', system-ui, sans-serif"></div>

// On render, the widget calls GET /api/v1/verify/{code}
// and renders the custody record inline. No iframe, no
// third-party cookies, no data crosses to FBC except
// the verification code itself.

Note   The widget is available at Tier 02 and above. Style tokens supported: data-theme, data-accent, data-font, data-paper, data-ink, data-radius. Email engineering@ for the full token reference.

§ 04 — REQUEST

Don't see your platform? Ask.

The connectors above are the ones we maintain in production. New connectors are built when a sponsor asks — usually because they're moving an SPV onto FBC custody and the portal in question is where their investors already log in. If you're ready to proceed, you can reach us via our contact page or review onboarding requirements on sponsor onboarding overview. Lead time is typically two to four weeks for a new connector; sometimes less if the platform has a clean partner API.

Email engineering@

What to include in the request

  • Platform name and version (if applicable)
  • Whether you're a current sponsor or evaluating
  • What the connector should do (push codes? embed widget? both?)
  • Approximate launch date for your next SPV
  • Any platform-specific contact you already have (helpful for partner API access)