This one automation could save you thousands a year.

Chapter 02 · The build

The workflow that does it for you

Now the fun part. We're going to replace those nine minutes with a workflow that runs in about thirty seconds and never forgets a step. It's built in n8n and talks to ServiceM8 over plain HTTP. Import the JSON at the end of this guide and you're most of the way there.

We're triggering it from email, because that's how leads actually turn up. A website form notification, a Facebook lead, a "can you quote this?" from a regular, even a forwarded enquiry: nearly all of it lands in an inbox. So the workflow watches a Gmail mailbox, and the moment a lead arrives it captures the sender, the message and any attachments, has AI write a tidy job description, files the whole lot into ServiceM8 as a job, then emails the customer back a branded confirmation with their job number.

Step by step

The bit everyone gets wrong: attachments are a two-step

You can't just push a file at a job in ServiceM8. An attachment is two separate calls, and they have to happen in order. First you create the attachment record, the metadata that says "a file named X, of type Y, belongs to this job". That gives you an attachment UUID. Then you upload the actual bytes to that record's .file endpoint. Skip the first step and there's nothing to upload into; the file has nowhere to live.

# Step 1: create the attachment RECORD (metadata only)
POST https://api.servicem8.com/api_1.0/attachment.json
  related_object       = job
  related_object_uuid  = {{ job_uuid }}
  attachment_name      = site-photo.jpg
  file_type            = .jpg

# Step 2: upload the actual FILE to that record's .file endpoint
POST https://api.servicem8.com/api_1.0/attachment/{{ uuid }}.file
  (the binary file as the body)

Web forms usually list the customer's uploads as links in the email body rather than as email attachments, so a small Code node fans each link into its own item, downloads the file, then runs the two-step once per file. One photo or ten, it just works. (If your leads carry real email attachments instead, the Gmail trigger can download those directly.)

Closing the loop: the customer hears back instantly

The last step is the one customers actually notice. A small heads-up matters here: the lead email comes from the form's notification address, not the customer, so we don't reply to it. Instead we send a fresh email to the customer's real address (the one we parsed out of the form body). We fetch the job's friendly number (the generated_job_id, which only comes back when you read the job after creating it), then send a branded HTML confirmation: your logo up top, a thank-you, their job number in black and white, and their submission played back in a clean table. A lead that emails at 9pm gets a real acknowledgement at 9pm, while the job's already sitting in ServiceM8 waiting for you.

Talking to ServiceM8: one header, fields you can read

No OAuth dance. ServiceM8's private API uses a single API key. Generate one under Settings → API Keys, create one Header Auth credential in n8n, and point every ServiceM8 node at it:

# In n8n: Credentials → Header Auth
Name:  X-API-Key
Value: your_servicem8_api_key

And a deliberate choice in how the calls are built: every request uses Send Body → Using Fields Below and Send Query Parameters, the same boxes you'd fill in by hand. Nothing is buried in a raw JSON blob, so you can open any node and read exactly what it sends. Looking up the category, for instance, is one GET with a filter:

# Find the category UUID by name
GET https://api.servicem8.com/api_1.0/category.json
    ?$filter=name eq 'Service Call'
# -> use the first result's uuid as the job's category_uuid