Skip to content

Changelog

Changelog

All notable changes to this SDK are documented here. The format follows Keep a Changelog, and versions follow Semantic Versioning.

This file is the canonical changelog. The public docs site at partner-sdk.opendoor.com/changelog mirrors this content for partners who don’t have access to the private GitHub repo.

[Unreleased]

No unreleased changes since the last release.

[1.3.2] - 2026-06-08

Added

  • OpendoorClient.getCustomerContact({ opendoorOfferRequestId }) on both JS and Ruby server SDKs. Returns { fullName?, email?, phoneNumber? } for the customer who submitted the questionnaire. Requires the offer to have reached OFFERED — earlier states return NOT_FOUND.
  • OpendoorClient.getCustomerContact() on the browser @opendoor/partner-sdk-client-js-core, mirroring the server SDK. Calls the partner’s BFF at the new POST /api/opendoor/v1/customerContact route (configurable via endpoints.getCustomerContact).
  • Auto-prefill of the confirm step in <ScheduleAssessmentFlow> (React + Vue). On mount the component now calls getCustomerContact(offerId) and pre-fills the customer name and phone fields. Partners that pass customerName / customerPhone props explicitly keep their existing behavior (the fetch is skipped when both props are set). Fetch failures (including the pre-OFFERED NOT_FOUND case) are silently swallowed — the form just stays empty for manual entry.
  • “Prefilling customer details” guide section at partner-sdk.opendoor.com/guides/components/schedule-assessment, covering the auto-fetch behavior, the new BFF route requirement, and the explicit customerName / customerPhone opt-out.

Notes

  • Adds a new required BFF route: POST /api/opendoor/v1/customerContact → opendoor.getCustomerContact(). The Express dev server, Rails demo, and both Cloudflare Pages demo function templates have it wired; partners need to add the matching route on their BFF for the auto-prefill to function. If the route isn’t wired the schedule flow degrades gracefully — fields stay empty for manual entry, no error surfaced.

[1.3.1] - 2026-06-05

Added

  • DTC_ONBOARDING_PAGE_IDS const + DtcOnboardingPageId type exported from @opendoor/partner-sdk-client-js-core (and re-exported from the React + Vue packages). The 17 page IDs in the DTC onboarding flow, in display order, as an as const tuple. Use them with skipPages for autocomplete and compile-time validation.
  • “Skipping pages” guide section at partner-sdk.opendoor.com/guides/components/dtc-onboarding, with a complete page-ID reference table and a homebuilder-branch example.

Changed

  • skipPages prop on <DtcOnboardingFlow> (React + Vue) is now typed as readonly DtcOnboardingPageId[] instead of string[]. Existing literal-array calls keep working (TS narrows literals); only callers passing a pre-declared string[] variable will see a type error. Practically non-breaking since v1.3.0 only shipped 2026-06-05 and the page IDs weren’t documented anywhere partner-facing.

Fixed

  • Removed the stale market prop row from the <DtcOnboardingFlow> props table in the docs site. The prop was removed from the component in v1.3.0 but the guide page kept listing it.

[1.3.0] - 2026-06-05

Breaking

  • Removed market prop from <DtcOnboardingFlow> (React + Vue). The prop was a no-op — never consulted by any showWhen condition, validator, or filter — and its docstring claim of controlling “market-dependent questions” was misleading. Partners passing market should simply delete the prop; there is no behavior change.

Added

  • skipPages?: string[] prop on <DtcOnboardingFlow> (React + Vue). Lets partners remove specific pages from the questionnaire entirely (e.g., skip the homebuilder question when the partner already knows the answer). The engine treats skipped pages as if their showWhen evaluated to false — they’re dropped from navigation, and downstream showWhen conditions still resolve against any pre-set initialAnswers. Complements initialAnswers, which pre-fills pages but still renders them.

Changed

  • OpendoorClient.getAssessmentSlots now uses GraphQL (JS + Ruby server SDKs) instead of the REST /partner-api-proxy/v2/exterior_assessment_slots route. Same method signature, same response shape — only the transport changes. This completes the REST→GraphQL migration across the SDK and unblocks deprecation of the partner-api cloudflare-worker.

Fixed

  • OpendoorClient.getAssessmentSlots was calling the wrong URL on the REST path — pointed at the partnership-bff GraphQL host (partner.simplersell.com) and missing the /partner-api-proxy basepath. The request silently fell through to the partner-dashboard-fe SPA which returned HTML, and the SDK threw Unexpected token '<', "<!doctype ".... Superseded by the GraphQL migration above, but relevant for anyone on a @next build between the two fixes. The bug was latent since v1.0.0 — Lennar’s IFO flow never exercised assessment slots, so the broken URL went unnoticed until the post-IFO scheduling work landed.

[1.2.0] - 2026-06-03

Breaking

  • Removed QualificationQuestions component from @opendoor/partner-sdk-client-react. Use DtcOnboardingFlow instead — same questionnaire engine with co-branding support.

Added

  • OpendoorClient.scheduleAssessment({ offerId, selectedInspectionTime, reminderPhone?, notes? }) on both JS and Ruby server SDKs. Schedules the pre-underwriting home assessment for an offer.
  • calendarType parameter on getAssessmentSlots — 'ASSESSMENT_VISIT' (default, pre-UW) or 'DILIGENCE_VISIT' (post-contract). Replaces the previously-hardcoded 'DILIGENCE_VISIT' default.
  • <ScheduleAssessmentFlow> component in @opendoor/partner-sdk-client-react and @opendoor/partner-sdk-client-vue — three-step wizard (slot picker → confirm details → success) themed via the SDK appearance prop.

Earlier versions

For history older than v1.2.0, ask your Opendoor contact — earlier releases predate this changelog.