Submit an Enquiry
Send a message through the storefront contact form. The store emails the enquiry to its configured contact address.
Endpoint
POST /api/shop/contact-usRequest Headers
| Header | Required | Description |
|---|---|---|
Content-Type | Yes | application/json |
X-STOREFRONT-KEY | Yes | Your storefront API key |
There is no Authorization header on this endpoint. Unlike Newsletter, sending a customer token changes nothing — the enquiry is not linked to an account, so include the sender's identity in the body.
Request Body
| Field | Type | Required | Max length | Description |
|---|---|---|---|---|
name | string | Yes | 255 | Sender's name. |
email | string | Yes | 255 | Sender's email address — must be well-formed, and it is where the reply goes. |
message | string | Yes | — | The enquiry body. No length cap is applied. |
contact | string | No | 50 | Phone number. No format rule — any string up to 50 characters is accepted, and an enquiry without it still succeeds. |
{
"name": "John Doe",
"email": "[email protected]",
"contact": "+1234567890",
"message": "I have a question about your products"
}Response
201 Created with a two-field acknowledgement:
| Field | Type | Description |
|---|---|---|
success | boolean | true when the enquiry was handed to the mail queue. |
message | string | Translated confirmation text. |
Nothing addressable comes back — no id, no record to fetch. The enquiry leaves as an email, so a client cannot list, track, or follow up on submissions through the API. Show the confirmation and treat the exchange as finished.
success Can Be false on a 201
The enquiry is queued, not sent inline, so the response confirms the hand-off rather than delivery. If queueing itself fails the response is still 201, but with:
{
"success": false,
"message": "Unable to send your inquiry at this time. Please try again later"
}Read success before showing a confirmation — the status code alone does not tell you whether the enquiry got through. Delivery after a successful queue is not reported at all.
Validation
The required fields are validated server-side and a failure returns 400, not the 422 used by most other write endpoints. All failures are reported together in one message, space-separated, so a body missing both name and message returns "The name field is required. The message field is required."
This Endpoint Is Public
The storefront key is the only credential, which means an unprotected form invites automated submissions and there is no per-address uniqueness rule to blunt them — the same message can be sent repeatedly. Rate limiting or a captcha in front of the form is the client's responsibility; the API applies no additional check.
Same Operation Over GraphQL
The createContactUs mutation takes the same four fields and returns the same success and message. Only the request shape differs.