Skip to content

Schedule Assessment Flow

The ScheduleAssessmentFlow component lets a customer schedule the pre-underwriting home assessment for an existing offer. It fetches available slots, lets the customer pick a date + time, and collects optional reminder phone number and gate-code / access instructions.

This is the pre-contract assessment — its artifacts feed underwriting before the final offer. It is distinct from the post-contract diligence visit, which is scheduled separately.

Basic usage

import {
ScheduleAssessmentFlow,
OpendoorProvider,
} from '@opendoor/partner-sdk-client-react';
import { OpendoorClient } from '@opendoor/partner-sdk-client-js-core';
const client = new OpendoorClient({ baseURL: '/api/opendoor/v1' });
function App({ offerId }: { offerId: string }) {
return (
<OpendoorProvider client={client}>
<ScheduleAssessmentFlow
offerId={offerId}
appearance={{ theme: 'minimal' }}
onScheduled={(visitId) => {
console.log('Scheduled visit:', visitId);
}}
/>
</OpendoorProvider>
);
}

Wrap the component in <OpendoorProvider> to supply the SDK client.

Required BFF endpoints

RouteBacking server SDK call
POST /api/opendoor/v1/assessmentSlotsopendoor.getAssessmentSlots({ ... })
POST /api/opendoor/v1/scheduleAssessmentopendoor.scheduleAssessment({ ... })
POST /api/opendoor/v1/customerContactopendoor.getCustomerContact({ ... })

The server SDK methods (getAssessmentSlots, scheduleAssessment, getCustomerContact) wrap the Opendoor partner-API. Wire the three routes on your BFF that proxy to them.

The customerContact route is what powers the automatic prefill of the customer’s name and phone on the confirm step.

Props

PropTypeDefaultDescription
offerIdstringRequiredThe opendoorOfferRequestId returned from createOffer
appearanceOpendoorAppearance{ theme: 'minimal' }Visual theme configuration
customerNamestringauto-fetchedPre-fills the name field on the confirm step. See Prefilling customer details
customerPhonestringauto-fetchedPre-fills the phone field on the confirm step. See Prefilling customer details
partnerLogoUrlstring-Partner logo URL (shown before the Opendoor logo in the component header)
showAttributionbooleantrueShow the “Powered by Opendoor” attribution
onScheduled(visitId: string) => void-Called with the new visitId after a successful schedule submission
onReady() => void-Called when the component has loaded slots and is ready for input
onError(error: Error) => void-Called on slot-fetch or schedule-submission errors
onClose() => void-Called when the close (X) button is clicked. When provided, the close button is rendered in the header
isReschedulingbooleanfalseWhen true, hides the gate-code / access-instructions section
supportPhonestring'888-352-7075'Phone number shown in the empty- and error-state branches as a manual fallback. Rendered as a tel: link

Styling

The component uses the appearance prop for theming, defaulting to the minimal theme. All standard tokens apply — colors, fonts, spacing, borders, and radii are shared with other SDK components like AddressEntry and DtcOnboardingFlow. See the Appearance guide for the full token list.

How it works

  1. On mount, the component calls getAssessmentSlots({ offerId }) to fetch available slots from your BFF.
  2. The customer picks a slot and (when not rescheduling) confirms gate-code / access instructions and a reminder phone number.
  3. On submit, the component calls scheduleAssessment({ offerId, selectedInspectionTime, reminderPhone, notes }). On success, it emits onScheduled(visitId).

Pair this component with DtcOnboardingFlow for partner trade-in flows: customer completes onboarding → offer is created and a preliminary offer is shown → customer schedules the assessment via this component → underwriting runs against the assessment artifacts → final offer is presented for contract signing.

Empty and error states

The component distinguishes between two failure shapes:

  • Error state — the slot fetch threw. Copy suggests retry, and the support fallback is shown.
  • Empty state — the slot fetch succeeded but the calendar contains zero availability for the home. Copy is steady-state, and the support fallback is shown.

Both states render the supportPhone as a tel: link so the seller has a path forward. Override supportPhone if your support flow has a different number.

Prefilling customer details

The confirm step asks for the customer’s name and a reminder phone number. Those values were already submitted earlier by DtcOnboardingFlow, so re-typing them is a wart in the flow.

By default, the component handles this for you. On mount, it calls client.getCustomerContact({ opendoorOfferRequestId }) and pre-fills the name and phone fields from the response. The user can still edit either field. If the fetch fails (e.g., the offer hasn’t reached OFFERED yet) the fields stay empty and the user fills them in manually — no error is surfaced.

Wire the POST /api/opendoor/v1/customerContact route on your BFF (see Required BFF endpoints) for this to work.

You can opt out of the auto-prefill by passing customerName / customerPhone explicitly — when either prop is set, the component uses your value instead of fetching:

<ScheduleAssessmentFlow
offerId={offer.opendoorOfferRequestId}
customerName="Jane Doe"
customerPhone="5551234567"
/>