Membership application forms

Membership tiers can collect structured answers when someone joins — including fields only you (the seller) fill in later from the roster.

This guide is for sellers configuring per-tier application forms and seller-only fields. For the broader memberships setup (tiers, approval, roster, renewals), see the Memberships doc.

Per-tier application forms

Each tier can have its own application form. Build and edit it in the tier editor.

Supported field types:

text, textarea, option, checkbox
email, phone
date, number, url

Each field has an id, type, label, required flag, options (where relevant), and an optional hidden flag.

Seller-only (hidden) fields

Mark a field hidden to make it seller-only:

Buyers never see it at join
You edit answers from the roster (application responses modal)
Values appear in member CSV export
Required is forced off for hidden fields when the form is normalised

Buyer submit only accepts visible fields. Hidden values from a buyer submit are rejected. Sellers validate against the full form (including hidden fields).

What buyers fill in

On both instant join and approval flows, buyers only see and complete visible fields. Answers are saved before charge / before the approval path continues.

On approval flows, notification emails can include the submitted answers, and you can optionally include a rejection reason when declining.

Field UI covers all nine types. URLs must be valid absolute http/https links. Dates use YYYY-MM-DD.

Roster and export

From the members roster you can:

Load a member’s application responses for a tier
Update responses (editors and above) — upserting a row if none exists yet when the tier has a form

Exports include resolved answers with one CSV column per form question.

Responses are keyed by seller, user, and tier; updates keep the latest answers for that key. Values are validated with length and item caps (long text and multi-value fields are bounded).

Good to know

This page does not document field reordering, orphaned answers after a form is deleted, a hard max field count, editing options after answers exist, or full answer history.
Keep buyer-facing questions visible; use hidden fields for internal notes you fill after someone joins.

Membership application forms

Membership tiers can collect structured answers when someone joins — including fields only you (the seller) fill in later from the roster.

This guide is for sellers configuring per-tier application forms and seller-only fields. For the broader memberships setup (tiers, approval, roster, renewals), see the Memberships doc.

Seller-only (hidden) fields

Mark a field hidden to make it seller-only:

Buyers never see it at join

You edit answers from the roster (application responses modal)

Values appear in member CSV export

Required is forced off for hidden fields when the form is normalised

Buyer submit only accepts visible fields. Hidden values from a buyer submit are rejected. Sellers validate against the full form (including hidden fields).

What buyers fill in

On both instant join and approval flows, buyers only see and complete visible fields. Answers are saved before charge / before the approval path continues.

On approval flows, notification emails can include the submitted answers, and you can optionally include a rejection reason when declining.

Field UI covers all nine types. URLs must be valid absolute http/https links. Dates use YYYY-MM-DD.

Roster and export

From the members roster you can:

Load a member’s application responses for a tier

Update responses (editors and above) — upserting a row if none exists yet when the tier has a form

Exports include resolved answers with one CSV column per form question.

Responses are keyed by seller, user, and tier; updates keep the latest answers for that key. Values are validated with length and item caps (long text and multi-value fields are bounded).