[Migration map](../reference/tool-name-migration.md).
# 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](publ_signup_form_apply.md) to change the form. The [workflow guide](../guides/signup-form.md) 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. |
```json
{"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](../reference/results.md) 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](../index.md).
