Create a threaded public feedback comment and subscribe the signed user ​
This Public Feedback operation is available through POST /s/{slug}/feedback/{feedbackId}/comment. Use the reference below to inspect its request contract and documented responses before connecting it to your application.
Send a POST request to /s/{slug}/feedback/{feedbackId}/comment on the appropriate server. Check the API overview for base URL guidance and the server information in the interactive reference. Replace path placeholders with identifiers from the intended account or site; a similarly named record in another workspace is not interchangeable.
The declared request parameters are:
slug (path, required): Use the type and constraints shown in the parameter reference.
feedbackId (path, required): Use the type and constraints shown in the parameter reference.
X-User-Token (header, required): Signed customer JWT with role admin or user
This operation defines a required request body. Documented media types: application/json. Review required fields, nested objects, and allowed values in the request schema. Keep identifiers and field types intact when replacing example data with your own values.
The specification lists these security alternatives: BearerAuth, AccessToken. Read any operation-specific restrictions as well: browser-session, account-role, and signed-user requirements may impose additional conditions. See authentication before choosing a credential.
Keep credentials in the appropriate private configuration and remove secrets from shared logs. Confirm the target resource belongs to the intended workflow before issuing a request. Authentication alone should not be treated as confirmation that a supplied account, site, or customer identifier is correct.
The documented responses for Create a threaded public feedback comment and subscribe the signed user are:
201: Created
401: Signed user token required
403: Token missing admin/user role
404: Feedback not found
Exercise this operation with controlled test data before enabling it in an automated workflow. Validate the request against the schema and inspect the response before updating local state. Do not assume that a successful response means background processing has finished; follow any documented status or follow-up operation when the action queues additional work.
If a connection fails after submission, investigate the current server state before repeating an action whose outcome is uncertain. When requesting support, retain the method, route, response status, and sanitized error message. The interactive reference below provides the detailed schemas and examples for this specific operation.
Create a threaded public feedback comment and subscribe the signed user​
Create a threaded public feedback comment and subscribe the signed user ​
This Public Feedback operation is available through
POST /s/{slug}/feedback/{feedbackId}/comment. Use the reference below to inspect its request contract and documented responses before connecting it to your application.Request preparation ​
Send a POST request to
/s/{slug}/feedback/{feedbackId}/commenton the appropriate server. Check the API overview for base URL guidance and the server information in the interactive reference. Replace path placeholders with identifiers from the intended account or site; a similarly named record in another workspace is not interchangeable.The declared request parameters are:
slug(path, required): Use the type and constraints shown in the parameter reference.feedbackId(path, required): Use the type and constraints shown in the parameter reference.X-User-Token(header, required): Signed customer JWT with role admin or userThis operation defines a required request body. Documented media types:
application/json. Review required fields, nested objects, and allowed values in the request schema. Keep identifiers and field types intact when replacing example data with your own values.Authentication and scope ​
The specification lists these security alternatives: BearerAuth, AccessToken. Read any operation-specific restrictions as well: browser-session, account-role, and signed-user requirements may impose additional conditions. See authentication before choosing a credential.
Keep credentials in the appropriate private configuration and remove secrets from shared logs. Confirm the target resource belongs to the intended workflow before issuing a request. Authentication alone should not be treated as confirmation that a supplied account, site, or customer identifier is correct.
Response handling ​
The documented responses for Create a threaded public feedback comment and subscribe the signed user are:
Exercise this operation with controlled test data before enabling it in an automated workflow. Validate the request against the schema and inspect the response before updating local state. Do not assume that a successful response means background processing has finished; follow any documented status or follow-up operation when the action queues additional work.
If a connection fails after submission, investigate the current server state before repeating an action whose outcome is uncertain. When requesting support, retain the method, route, response status, and sanitized error message. The interactive reference below provides the detailed schemas and examples for this specific operation.
Create a threaded public feedback comment and subscribe the signed user​
Authorizations​
JWT token from login
Personal access token. Value:
Token <your-token>Parameters​
Header Parameters
Signed customer JWT with role admin or user
Path Parameters
Request Body​
Responses​
Created
Playground​
Authorization
Headers
Variables
Body
Samples​