Everything the portal's embedded feedback widget needs to render its form, in one read.

Called when the form opens, not when the page loads. The widget fetches its signed token from your own server at that moment and uses it here, which is why an hour-long token is comfortable: the window only has to cover somebody writing, not their whole visit.

The fields come from the portal every time. A PM adding a required field appears in the widget on the next page load with nobody editing your site — which is the point of embedding the portal's own form rather than a copy of it. Each field carries required, so the widget can catch a missing one before posting instead of by a rejection.

Read this when the widget OPENS, not when the page loads. Everything here is a setting an administrator can change at any moment, so the response is Cache-Control: no-store and a copy held across a long-lived page goes out of date. Nothing can make this read and the submission that follows one transaction, which is why a stale importanceId is forgiven on submit rather than refused — but the fresher this read, the less often a submitter is shown an option that has since gone.

One list, already in order. A form's built-in fields — its description box — are the portal's to show, hide, reorder and mark required, exactly like a field somebody created, so a page that hardcodes them drifts the moment an administrator changes their mind. Both kinds arrive merged in fields, sorted the way the form editor arranges them — the description box can sit between two created fields, and it will here too. Draw the array top to bottom.

Each entry carries kind, which is also where its value goes on submit: a custom field's belongs in customFields under its id, a system field's is the request property its id names.

The categories are the widget's, narrowed here. A widget offers a chosen set; that narrowing is applied server-side, so what comes back is exactly what the form may show. Every offered category is covered by exactly one form: a category with no form of its own gets the portal's default form, which is the same form the submission will be validated against.

widget.hideImportance means leave the row out, not disable it. Draw no importance control at all, and post widget.defaultImportanceId as the importanceId — that is the answer the administrator gave in place of the submitter's, which is the point of hiding the question rather than a detail of it. A null there means nobody picked one: post no importanceId and the portal's default applies.

defaultImportanceId is already resolved. An administrator deleting the importance a widget named does not break it and does not rewrite it: the fallback to the first of importances is worked out on every read and nothing is written back, so restoring the importance restores the choice.

So do the words. terminology carries the portal's own names for feedback and for a company — { default, customSingle, customPlural } for each, always both keys, defaults filled in when nobody has renamed anything. A portal that calls feedback a "Request" gets a form that says Request, for the same reason it gets the portal's fields: a copy of the form hardcodes the word and keeps saying it after a PM changes it.

No cookie is set and no Craft session exists — on this call or on the submission that follows it. That is a property of the feature rather than an implementation detail: nothing about the person browsing your site is stored in their browser by Craft.