Create Contact Us

Send a message through the storefront contact form. The store emails the enquiry to its configured contact address.

This mutation is public — the storefront key is the only credential, and a customer token changes nothing. The enquiry is not linked to an account, so identify the sender through name and email even for a signed-in customer.

Arguments

Argument	Type	Required	Description
input	createContactUsInput!	Yes	Input object containing the contact-form fields.

Input Fields (createContactUsInput)

Every field is nullable in the schema — the requirement is enforced by server-side validation, not by the type, so omitting name is a valid query that fails at execution.

Field	Type	Required	Max length	Description
name	String	Yes	255	Sender's name.
email	String	Yes	255	Email address to reply to. Must be well-formed.
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.
clientMutationId	String	No	—	Echoed back on the response.

Possible Returns

Field	Type	Description
contactUs.success	Boolean	true when the enquiry was handed to the mail queue.
contactUs.message	String	Translated confirmation text.
clientMutationId	String	Echoed from the input when provided.

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. Show the confirmation and treat the exchange as finished.

success Can Be false Without an Error

The enquiry is queued, not sent inline, so the response confirms the hand-off rather than delivery. If queueing itself fails the mutation still resolves normally, with no errors array, and returns:

{
  "success": false,
  "message": "Unable to send your inquiry at this time. Please try again later"
}

Read success before showing a confirmation — the absence of errors does not mean the enquiry got through. Delivery after a successful queue is not reported at all.

Validation

Required fields are validated server-side. A failure surfaces as a top-level errors entry with every problem joined into one string, so a submission missing both name and message returns "The name field is required. The message field is required." rather than two separate entries.

Guard the Form Yourself

The storefront key is the only credential, and there is no uniqueness rule — the same message can be submitted repeatedly. An unprotected public form invites automated submissions, so rate limiting or a captcha in front of it is the client's responsibility; the API applies no additional check.

Same Operation Over REST

POST /api/shop/contact-us takes the same four fields and returns the same success and message. Only the request shape differs.