contactDetailsSubstore

Manages the contact information the user fills in before submitting a request. This includes two fixed fields (name and email) and a set of dynamic request fields loaded from the API. All fields perform inline validation on change.

Table of contents

Properties

• tempPreConfigRequestFields
• initialRequestFieldsData
• requestFieldsData
• requestFieldsValues
• requestFieldsErrors
• fixedContactDetails

Methods

• setSubFieldValue
• setFixedContactDetailsValue

---

Properties

tempPreConfigRequestFields

tempPreConfigRequestFields: TPreConfigRequestFields | undefined

Temporary pre-config request field overrides, automatically cleared after they are applied.

When configsSubstore.setupFromPreConfig is called with a preConfig that contains request-field values, those values are written here first. The substore then consumes them to pre-fill requestFieldsValues and immediately sets this property back to undefined.

Each requestFieldId in the pre-config is matched against sub-field slug or text (case-insensitive). Prefer slug when generating pre-filled links.

Related

• configsSubstore.setupFromPreConfig — populates this property
• requestFieldsValues — receives the values from this property

---

initialRequestFieldsData

initialRequestFieldsData: ApiResource<TRequestField[]>

Complete request-field definitions as returned from the API (after filtering inactive groups), including hidden sub-fields.

The SDK uses this resource internally for validation, pre-config matching, select-value localization, and session reset defaults. Integrations that need to submit hidden or readonly values should read values from requestFieldsValues — those keys still exist for every sub-field defined here, even when the sub-field is not shown in requestFieldsData.

Related

• requestFieldsData — UI-facing subset (hidden sub-fields removed)
• setSubFieldValue — only updates sub-fields with mode: "editable"

---

requestFieldsData

requestFieldsData: ApiResource<TRequestField[]>

API resource containing the dynamic request-field definitions for rendering, including loading and error state.

This is derived from initialRequestFieldsData: sub-fields with mode: "hidden" are stripped out, and empty groups are removed. Hidden fields are omitted from the checkout UI but their values can still be set via pre-config or API defaults and are included in submission.

Each TRequestField describes a field group with one or more sub-fields (e.g., a company address field with street, city, and postal-code sub-fields). Each sub-field has a name, an optional slug, a text label, a required flag, and a mode:

mode	UI behaviour	User can edit via SDK
"editable"	Shown as a normal input	Yes — setSubFieldValue
"readonly"	Shown but not editable	No — values come from defaults or pre-config
"hidden"	Not listed in requestFieldsData	No — not shown; value still stored if present

The UI should render each visible sub-field according to its type:

Type	Description
text	Single-line text input
number	Numeric input
textarea	Multi-line text input
checkbox	Boolean; stored as "true" / "false"
select	Dropdown with predefined options (see below)

Select sub-fields include an options array. Each option has a slug, a label, and optional per-language labels (e.g. da_label). Store the selected option’s label via setSubFieldValue. When the user changes language, the SDK re-localizes stored select values automatically.

See ApiResource for the shape of loading/error state.

Related

• requestFieldsValues — stores user-entered values keyed by the field/sub-field IDs from this data
• requestFieldsErrors — validation errors keyed by the same IDs
• setSubFieldValue — updates a value and re-runs validation

---

requestFieldsValues

requestFieldsValues: {
  [requestFieldId: number]: {
    [requestSubFieldId: number]: string
  }
}

Current user-entered values for all request fields, keyed by field ID and sub-field ID.

Initialised to empty strings. Updated by setSubFieldValue. The entire structure is sent to the API when submitting (see submitSubstore.submit).

Related

• requestFieldsData — source of the field/sub-field ID structure
• setSubFieldValue — updates individual values
• requestFieldsErrors — validation state for these values
• tempPreConfigRequestFields — can bulk-initialise these values

---

requestFieldsErrors

requestFieldsErrors: {
  [requestFieldId: number]: {
    [requestSubFieldId: number]:
      | false
      | "missing"
      | "invalid-number"
      | "unchecked-checkbox"
      | "invalid-option"
  }
}

Validation error state for all request fields, keyed by field ID and sub-field ID.

Errors are recomputed automatically when requestFieldsValues change (and when request-field definitions load). You do not need to validate manually after each keystroke.

false means the field is valid. String values indicate the type of error:

Error	When
"missing"	Required field is empty
"invalid-number"	Required number field is not a valid number
"unchecked-checkbox"	Required checkbox is unchecked
"invalid-option"	Required select field value does not match any option

Fixed name and email errors are kept in sync with fixedContactDetails values the same way.

Related

• requestFieldsValues — the values being validated
• setSubFieldValue — triggers revalidation on change

---

fixedContactDetails

fixedContactDetails: {
  id: "name" | "email";
  value: string;
  error: false | "missing" | "invalid-email";
}[]

The fixed name and email contact fields with their current values and validation error states.

Always contains exactly two entries (one for "name", one for "email"). Updated by setFixedContactDetailsValue.

Related

• setFixedContactDetailsValue — setter
• submitSubstore.submit — reads name and email from here to build the submission payload

---

Methods

setSubFieldValue

setSubFieldValue: (args: {
  requestFieldId: number;
  requestSubFieldId: number;
  value: string;
}) => void

Updates a specific sub-field value and revalidates it immediately.

After writing the new value to requestFieldsValues, the SDK synchronously recomputes the error entry in requestFieldsErrors for this sub-field.

Parameters

Name	Type	Description
args.requestFieldId	number	ID of the parent request field
args.requestSubFieldId	number	ID of the sub-field to update
args.value	string	New string value

Related

• requestFieldsValues — updated by this call
• requestFieldsErrors — revalidated by this call

---

setFixedContactDetailsValue

setFixedContactDetailsValue: (args: {
  id: "name" | "email";
  value: string;
}) => void

Updates a fixed contact field (name or email) and runs validation on the new value.

After writing the value, the SDK synchronously validates it:

• "name" — checks the field is not empty
• "email" — checks the field is not empty and matches a valid email pattern

Parameters

Name	Type	Description
args.id	"name" | "email"	Which fixed field to update
args.value	string	New string value

Related

• fixedContactDetails — updated and revalidated by this call