Architecture

Backend-for-Frontend (BFF) pattern

The SDK uses a proxy pattern where your frontend never talks to Opendoor directly:

Partner Frontend (React)
  → client-js-core (HTTP client)
    → Your Backend (Express, Next.js, etc.)
      → server-js-core (Opendoor SDK)
        → Opendoor Partnerships API (GraphQL + REST)

Why this pattern?

Security — Your Opendoor API key stays on your server. The browser SDK has no knowledge of the API key, GraphQL endpoint, or Opendoor’s internal APIs.

Flexibility — You control the middleware. Add rate limiting, logging, caching, or transform the data before returning it to the frontend.

Simplicity — The browser SDK makes simple REST calls to your own backend. The server SDK handles the complexity of communicating with Opendoor — GraphQL for offers, REST for address suggestions — so your backend code stays straightforward.

The three packages

@opendoor/partner-sdk-server-js-core

Node.js client that wraps the Opendoor Partnerships API. It uses:

• GraphQL for offer operations (createOffer, updateOffer, getOffer)
• REST for address suggestions (Cloudflare Worker) and assessment slots

You call client.createOffer({ address }) — the SDK routes to the right backend.

@opendoor/partner-sdk-client-js-core

Framework-agnostic browser HTTP client. Makes typed fetch calls to your backend’s /api/opendoor/v1/* endpoints. Also defines the OpendoorAppearance theming contract used by React components.

No React, no DOM, no CSS. Can be used with any framework or vanilla JS.

@opendoor/partner-sdk-client-react

React components that use the client SDK via an OpendoorProvider context. Components accept an appearance prop for visual customization and expose lifecycle callbacks for integration.