signup_form_get — read sign-up form settings
Read which information a selected channel asks members to supply. The result describes 47 form definitions and their enabled/required state; it does not read answers, create a member, or register a publ account. Use signup_form_apply to change the form. The workflow guide lists the keys and connects planning, saving and recovery.
Input and prerequisites
| Field | Type | Required | Meaning |
|---|---|---|---|
channelCode |
string | Yes | Nonempty selected channel code; . and .. are rejected. Extra input properties are rejected. |
{"channelCode":"selected-channel-code"}
Obtain the code through authorized channel discovery or the bound hosted resource. The HTTP adapter requires a selected-channel credential with OWNER role, or DELEGATEE role and MANAGE_CHANNEL_PUBLIC_SETTING. CREATOR and a delegate without that permission are rejected. The server remains authoritative for token validity and authorization.
The separate CHANNEL_MANAGEMENT service origin must be configured. The bundled development origin is selected by the development environment; production/custom environments require their own verified configuration. The adapter resolves channel context, requires its returned code to match, then sends GET /seller/api/v1/profile-additional-information-fields with the selected-channel bearer and x-publ-channel-id. Before the form request it checks connection identity and the current token's publication permission. These checks do not provide an atomic channel/permission snapshot.
Inputs
This tool takes no input fields.
Result
A successful business payload has status:success, code:SIGNUP_FORM, taskType:signup-form, environment and channel context, and:
| Field | Meaning |
|---|---|
fields |
All 47 definitions, in canonical order. Each includes key, label, category, dataType, format, editable, enabled, required, and source. Only CUSTOM entries have name. |
revision |
Lowercase SHA-256 over normalized fields and missing keys. Use it unchanged as apply's expectedRevision. |
missingKeys |
Editable keys absent from a nonempty server response. |
canApply |
True only when no editable keys are missing. It is not authorization for a particular proposed change. |
impact |
Reminder that enabling questions may affect existing members, and renaming does not confirm recollection. |
verification |
method:form_settings_read, confirmed equal to form completeness, memberAnswersRead:false, memberRecollectionVerified:false. |
The three ESSENTIAL definitions (email, nickname and country) are always enabled, required and not editable. The other definitions comprise 39 fixed questions and five CUSTOM slots. enabled controls collection; required controls mandatory answers. Data types and formats describe the form, not accepted inputs for editing members' answers.
Labels include English and quoted original UI labels. Use key, never a translated label or a server record ID, to select a field. Fixed questions have no editable name. Missing optional definitions still appear in the view with editable:false, enabled:null, required:null and, for CUSTOM, name:null.
Empty forms, incomplete forms and revision
| Server observation | Interpretation |
|---|---|
| Exactly an empty array | Supply the original screen's initial values: all 44 optional fields disabled/not required and custom names blank. No write occurs. Their source is empty-form-screen-default; canApply:true. |
| Nonempty valid array with all editable keys | Use saved values, with source:server on optional fields. |
| Nonempty valid array missing editable keys | Preserve the missing state, with source:missing, canApply:false and verification.confirmed:false. Do not invent replacements. |
| Missing/null/malformed array, unknown keys, duplicate IDs/keys or incompatible types/states | Return SIGNUP_FORM_UNVERIFIED; never interpret these as an empty form. |
Essential definitions always have source:fixed-screen-contract, including when the server omits them. Invalid essential records, when supplied, are rejected. Records must have positive integer IDs and matching CONFIG/CUSTOM types; required-but-disabled records and nonempty custom names on CONFIG records are rejected. Nullable custom names normalize to the empty string.
The revision includes effective field values and missing keys, but excludes server record IDs, display labels and whether defaults came from an empty response. A first save can therefore match the same effective values despite replacing defaults with server records. This is a client comparison token, not a server conditional-write lock. It does not version member answers.
Failures, navigation and limits
Missing service configuration produces CHANNEL_MANAGEMENT_ORIGIN_REQUIRED; credential/role/context failures remain errors, including CHANNEL_CREDENTIAL_MISSING, CHANNEL_SETTINGS_ROLE_DENIED, CHANNEL_CONTEXT_MISMATCH or CONNECTION_CHANGED. Upstream rejection is not an empty form. See common results for application versus protocol errors.
At this fixed revision, successful non-demo results with a resolved target supply exactly one console destination at /channels/{encodedChannelCode}/publish/sign-up-form, using the configured console origin. The legacy consoleUrl is the same URL as navigation.primaryUrl. A link does not prove browser access or that the console shows the API environment.
A complete read proves normalized form settings were obtained. It does not confirm visitor sign-up, rendered controls, recollection from existing members or hosted production isolation. Use the separate member-detail workflow when authorized to read actual responses; see the Reference index.