Revised field limits
A string value in metadata or in a custom fields value may now be 1000 characters, up from 500. Nothing else about either shape changed: metadata is still capped at 10 keys and still stamped once at creation, custom fields are still typed and still validated against the waitlist's definitions.
The old limit was set for short values — a company name, a plan tier — and a free-text note is the thing people actually kept hitting it with. 500 characters is about a paragraph; a "what are you hoping to use this for?" answer runs past it more often than not, and the request came back a 400 with the answer already typed.
The two limits are now one number rather than two that happened to agree. metadata is immutable after creation and custom fields are not, so a value in the wrong one gets moved; discovering a different length limit on the other side of that move was a second surprise on top of the first.
Field values may now contain newlines too. They were rejected at the API's front door to keep a line break out of an email subject, which charged every value — including the ones no template interpolates — for a rule about a single line of output. The email body already rendered them correctly: a line break becomes a <br />, a blank line starts a new paragraph. Only the subject cannot span lines, and that is now handled where it happens, by collapsing newlines to spaces as the subject is rendered.
That split matters because the two halves of a subject line come from two different people. The account owner writes the template and chooses whether {{note}} belongs in the subject; whoever fills in the signup form supplies the text. No amount of care on the owner's part stops someone pasting two lines into a free-text field, so the failure landed on the person who could not prevent it.
One limit went the other way: a waitlist may now define at most 20 custom fields. There was no cap before, and with none, the size of a signup request had no bound at all — 20 fields at 1000 characters each is the ceiling that number now sets, and those values are carried by every list response and every CSV export thereafter. Twenty is well past any real signup form; a form longer than that is an application, and an application wants a form builder rather than a waitlist.
It is a flat limit, not a plan one. The quotas in your plan meter capacity, which a delete frees up again; a field definition is structure. An account moving to a smaller plan with a dozen fields already defined would be over a plan-varying limit with nothing sensible to do about it, and nobody upgrades a waitlist to buy form fields.
Raising a limit accepts everything it accepted before, so the two length changes need no migration and no version pin. If you are validating lengths on your own side before calling us, those are the numbers to change. The field cap only applies when creating a new definition — no existing waitlist is affected, and if you somehow have more than 20 fields today they all keep working.