Changelog

Custom fields

Waitlists now support strongly-typed field definitions. Define the fields you want to collect at signup time — company name, team size, plan tier, anything — and they are validated automatically on every signup, stored on the row, and available as {{key}} placeholders in the welcome email template.

How it works:

  1. Define fields on a waitlist via the API (POST /v1/waitlists/:id/fields). Each field has a key, label, type (string, number, or boolean), and an optional required flag.
  2. Pass values in the fields object when adding a signup. Required fields that are missing return 400. Unknown keys are stripped silently.
  3. Values appear in the signup response and are stored permanently on the signup row. Use {{company}} (or whatever key you defined) in your welcome email template.

API surface:

MethodPathReturns
GET/v1/waitlists/:id/fieldsAll field definitions
POST/v1/waitlists/:id/fieldsCreated field definition
PATCH/v1/waitlists/:id/fields/:keyUpdated field definition
DELETE/v1/waitlists/:id/fields/:key204

key is immutable after creation. label, required, and position can be updated. Deleting a definition does not touch existing signup values.

SDK: waitlists.fields.list(), .create(), .update(), .delete() — all on @enlistdev/sdk@0.3.0.

MCP: list_waitlist_fields tool added. add_signup now accepts fields. Both on @enlistdev/mcp@0.3.0.

Constraints: field keys must be lowercase alphanumeric + underscores (e.g. company, headcount) and cannot shadow built-in template variables. Values are checked against the declared type, and there are limits on how long a value may be and how many fields a waitlist may define — see the API reference for the current numbers.

Latest updates

Custom fields · Enlist