API intake channel
Prepare a supported API intake workflow for systems that need to create support requests.
On this page
Overview
The API pane describes authenticated programmatic ticket intake in the elegant-support/v1 REST namespace. Use the ticket endpoint and the current request schema rather than submitting to the public web form.
When to use this
Mobile apps and backend jobs should open tickets without scraping the web form. Central REST keeps capabilities and rate limits in one place.
Where to find the controls
Settings → Support Channels → API. Related: Settings → Integrations for webhooks/Slack/WooCommerce. REST namespace elegant-support/v1 (System Status).
Who can make these changes
Developers with application passwords or authenticated WP users that hold create_ticket (or a dedicated integration user). manage_settings to read the pane.
Before you begin
Create a least-privilege WordPress user with elegant_support_create_ticket (and view/manage customer if you send customer payloads). Store credentials in the app, not in KB. Webhooks for outbound events are a different pane.
Follow these steps
- Open the API pane and read the intake notes.
- Confirm permalinks so /wp-json/elegant-support/v1 resolves.
- Authenticate.
- POST a ticket using Form Builder keys for custom fields.
- Verify Inbox.
- Handle 401/403 as session or capability failures.
Settings reference
Authentication and ticket payload requirements are defined by the REST controller. Inspect the endpoint schema for accepted keys and data types. Treat 401 as authentication failure, 403 as denied access, and 404 as a missing route or inaccessible record.
Example workflow
An authenticated integration creates a ticket for a known customer_id with subject, description, and supported custom_fields. Confirm the user can access that customer and the field keys are present on the admin surface. Inspect the resulting channel_type; an unsupported manual channel is normalized to web_form, so an API request does not imply a separate API channel label.
Good practices
Send the same field keys the Form Builder shows. Exclude REST from caches. Rotate application passwords after staff leave.
Important considerations
Do not expose manage_settings credentials to a storefront. IDOR rules still apply: never accept a client-supplied “view any ticket” id without a capability check on the server (already enforced — do not bypass).
If something does not work
REST 404: permalinks. 401: cookie/nonce/application password. 403: missing cap. Ticket missing custom fields: keys not in schema. Contact support with the REST route and status, never with secrets.