Also i tried as it is recommended in tutorial and used “attachments”: [“bc55a2fb-86eb-4072-839c-23f5eb131d9b”]. But then it just gives an error message “{“errorCode”:420,“message”:“Attachment UUID [bc55a2fb-86eb-4072-839c-23f5eb131d9b] does not exist”,“messageID”:“3b5c0c19-9656-4bb4-ba22-23f5e07969eb”,“submittedAt”:“2026-03-16T18:58:20+00:00”}“
Good afternoon. I am following up on my request earlier. can you please point out where I should search for the answer on my question? I saw some similar topics with similar requests dated in 2018-2020, and none of them were answered. Does this mean there is no solution for it yet?
For /platform_service_email, the attachments field needs to be a JSON array of attachment UUIDs (not a single string), and each UUID must reference an existing attachment in ServiceM8.
Also worth noting: the ServiceM8 Messaging API (including /platform_service_email) is only available to Public Applications, and it requires OAuth 2.0 (access token) rather than API-key auth.
A good way to sanity-check the UUID you’re passing is to fetch the attachment record via the Attachments API (attachments include photos, PDFs and other user-attached files) and confirm it exists in the same account you’re sending the email from. For example, try retrieving it with GET /dboattachment/{uuid}.json.
Once you’ve done that, reply here with the response you get from GET https://api.servicem8.com/api_1.0/dboattachment/bc55a2fb-86eb-4072-839c-23f5eb131d9b.json (remove anything sensitive) so we can confirm why the Messaging API isn’t recognising it.
The /platform_service_email endpoint is part of ServiceM8’s Messaging API, and the developer docs state this Messaging API is only available to Public Applications and requires OAuth 2.0 (access token) to use.
For attachments, the API expects attachments to be a JSON array of Attachment UUIDs, and each UUID must reference an existing attachment in the system.
A couple of things to check:
Authentication: if you’re using an API key (X-Api-Key) today, note that the docs describe API keys under “Private Applications”, while the Messaging API is documented as Public-app (OAuth 2.0) only.
Payload format: send attachments as an array, e.g. "attachments": ["bc55a2fb-86eb-4072-839c-23f5eb131d9b"].
Confirm the UUID is an Attachment record: you can verify the attachment exists by retrieving it via the Attachments API (e.g. GET https://api.servicem8.com/api_1.0/dboattachment/{uuid}.json).
If you need to create/upload the attachment first: the documented workflow is to create an attachment record and then submit the binary file data for that attachment (the “Attaching files to a Job Diary” guide walks through this).
Once you’ve confirmed whether GET /api_1.0/dboattachment/{uuid}.json succeeds for that UUID, reply here with the HTTP status code you get (no credentials) and we can point you in the right direction.
You were absolutely right in your observation. I wanted to clarify in more detail what’s happening on my end and the logic behind the current workaround I implemented.
When I generate the job material (invoice), the system returns a UUID. However, this UUID appears to be temporary and is not actually linked to a usable attachment record in ServiceM8. In other words, while the invoice is created successfully, there is no immediately accessible attachment UUID that I can use to include the invoice as a file in an email.
Because of this limitation, I implemented a temporary workaround:
After generating the invoice, I use the returned UUID to send a “dummy” email to myself with that UUID included as an attachment reference.
When this email is processed by the system, ServiceM8 automatically creates a proper attachment record associated with the job.
This results in a valid attachment UUID being generated and stored against the job.
I then fetch the attachment UUID associated with that job using the API.
Finally, I use this correct attachment UUID to send the actual email to the customer with the invoice attached.
This approach has been working reliably so far, as it effectively forces the system to create the attachment object that is otherwise not directly available after invoice creation.
I understand that this is not the most efficient or ideal solution, and it introduces an extra step that depends on email processing. If there is a more direct or recommended way to retrieve or generate a valid attachment UUID for an invoice (without needing to trigger it via email), I would really appreciate your guidance.
Thanks again for your help, and I look forward to your suggestions.
A supported way to generate a real Attachment record for an invoice (so you can reference it in the Messaging API) is to use the Document Templates API to produce an Invoice PDF and set storeToDiary=true, which automatically attaches a copy to the job diary.
From there, you can fetch the new attachment UUID and pass it to /platform_service_email (which expects attachments to be an array of UUIDs, and each UUID must reference an existing attachment record).
A typical flow looks like this:
Produce the invoice PDF and store it to the job diary
templateUUID is optional (if omitted, your default Invoice template is used)
Find the attachment record that was created
Use GET /api_1.0/attachment.json with filtering
For example: GET /api_1.0/attachment.json?$filter=related_object eq ‘job’ and related_object_uuid eq ‘<job_uuid>’ and attachment_source eq ‘INVOICE’
Send the email with that attachment UUID
Send the email via /platform_service_email using “attachments”: [“<attachment_uuid>”]
One other important detail: the Messaging API is only available to Public Applications and requires OAuth 2.0 (access token) to use.
Once you’ve tried the /platform_produce_document + filtered /attachment.json lookup, reply here with whether you can see an attachment_source = INVOICE attachment for that job (no credentials), and we can confirm you’re pulling the right UUID.