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:
POST /v1/waitlists/:id/fields). Each field has a key, label, type (string, number, or boolean), and an optional required flag.fields object when adding a signup. Required fields that are missing return 400. Unknown keys are stripped silently.{{company}} (or whatever key you defined) in your welcome email template.API surface:
| Method | Path | Returns |
|---|---|---|
GET | /v1/waitlists/:id/fields | All field definitions |
POST | /v1/waitlists/:id/fields | Created field definition |
PATCH | /v1/waitlists/:id/fields/:key | Updated field definition |
DELETE | /v1/waitlists/:id/fields/:key | 204 |
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.