POST /feedback_portal/{portalId}/feedback

Email address of the person who submitted the feedback.

Resolved against this portal, in order: an administrative user of the portal, then an existing portal user with that address. If neither matches, a portal user IS CREATED for the address — they hold no password and can never sign in, they simply exist so the feedback is attributed to them and so their next submission resolves to the same person. The new user is homed in company when you send one. Otherwise the company is inferred from the address: an existing portal company whose people already use that email domain, else a new company named for the domain. An address at a free-mail or disposable domain infers nothing — gmail.com is not a customer — so those submitters go to the portal's "Individual Submitters" company, which is created on first use and holds everyone whose company is not determinable.

Omit it and the feedback is attributed to the portal's anonymous submitter (the same as sending anonymous: true).

This is NOT a user ID — sending anything that is not an email address returns 422 (owner must be a valid email address), like every other value error here.

The widget this submission came from — send it on every widget submission.

It names the configuration the form was rendered from, so the settings an administrator made per widget are applied to the submission rather than having to be echoed back by the page. Today that is the importance: a widget whose form does not ask (hideImportance) submits no importanceId, and the widget's own defaultImportanceId is applied here instead of the portal's default. Anything else that becomes per-widget will be applied the same way, with no change needed in the page.

A widget id this portal does not have is a 422 on an API key and is ignored on a widget credential. An administrator can delete a widget while a page is open, and a submission somebody has already typed must not be lost to it — the portal's default applies, exactly as a submission naming no widget would get. An API key can re-read and retry, so it is told.

Omit it and nothing per-widget is applied; the portal's own defaults stand. An explicit importanceId always wins over the widget's.

Portal importance — numeric ID OR exact name (case-insensitive). When omitted, the portal's isDefault: true importance is used (see GET /feedback_portal/{portalId}/importances) — or, when widgetId names a widget that hides the importance question, that widget's defaultImportanceId.

Customer company — numeric ID OR exact name (case-insensitive). Resolve via GET /feedback_portal/{portalId}/companies.

Sets the feedback's company, and is also the company a submitter created from owner is placed in. A value that matches no company in this portal is a 422 listing the valid ones; it is never created and never silently ignored.

Only settable on restricted portals — a public portal attributes everything to its default company, so sending it there is a 422.

Submit without attributing the feedback to a person: the item is attributed to the portal's anonymous submitter, so it reads as anonymous everywhere.

This is the explicit form of what omitting owner already does — send it when you want the intent to be visible in the request rather than inferred from an absent field.

Mutually exclusive with owner — sending both returns 422. company is still honoured, so anonymous feedback can still be grouped under a customer company.

Your own identifier for this submitter — the primary identity key when you send it.

Prefer it over relying on owner alone. Matching on your id rather than on an email address is what makes one address belonging to several of your tenants resolve to several distinct people instead of collapsing into one, and it survives the person changing their email.

Send it and owner together: the id is how the submitter is matched, and the address is how they are notified, so owner is still required.

Adding it later is safe. If you have been submitting without it, the first submission that carries an id is matched by owner and the id is adopted onto that existing person — your submitters are upgraded, not duplicated. From then on the id is what identifies them.

At most 255 characters; longer returns 422 rather than being truncated, because a truncated id would silently resolve to the wrong person. Compared exactly, including case.

Which of your systems submitterId came from. Only meaningful alongside submitterId.

Send it when more than one of your systems posts to the same portal: user 42 in your billing app is not user 42 in your analytics app, and without an issuer they would resolve to one person. With one system you can omit it — it defaults to this portal.

The same value the browser/widget route carries as its token iss claim, so a submitter resolves to the same person whichever route their feedback arrives on.

At most 255 characters; longer returns 422.

The submitter's name, as your own system holds it.

Send it and the portal shows a person. Omit it and the only name Craft can produce is the local part of owner, so jane.doe@acme.com reads as "jane.doe" on every card and in every digest.

Refreshed on every submission that matches, not only on the first one — the same as owner. If the person is renamed in your system, the next submission carrying their submitterId updates the stored name, so you never have to reconcile it separately.

One string, not first/last: it is split on the last space for storage and joined back for display, so what you send is what the portal shows.

Requires pass-through identity on the portal, like submitterId, and requires owner — a name with nobody to attach it to is a 422 rather than a value quietly dropped.

At most 256 characters; longer returns 422 rather than being truncated.

The page this feedback was submitted from — including its query string.

The query string is the point, not an incidental: a tenant, an account or a product area often sits in a URL parameter, and a PM reading the feedback item needs the link that reproduces what the submitter was looking at. Nothing is stripped, re-encoded or normalised.

In a single-page application send the URL in view at submit, not the one the page first loaded with — they are usually different and only the first is useful.

Must be an absolute http:// or https:// URL of at most 2048 characters. Anything else (a relative path, a javascript: or data: URL, surrounding whitespace, a NUL byte) returns 422 rather than being stored or quietly cleaned up.

Optional, and omitting it is the ordinary case for a backend integration that has no page.