Since approximately 7 July 2026, all POST requests to https://api.servicem8.com/api_1.0/Attachment/{uuid}.file return:
{"errorCode":400,"message":"Invalid data format supplied in request body","documentation":"Please refer to https://developer.servicem8.com/llms.txt for developer documentation."}
We note the error response uses a new errorCode/message schema and references llms.txt, and the “Create a new Attachment” reference page was updated roughly a week before this began — which suggests a recent validation-layer rollout may have affected the .file endpoint.
Could you please confirm:
Has the expected request format for POST Attachment/{uuid}.file changed? If so, what is the correct format now?
If not, can this be escalated as a regression? It currently breaks file uploads following your own documented example.
Happy to provide additional request traces if useful.
The documented attachment upload flow is still to create the Attachment record first, then upload the file data to POST https://api.servicem8.com/api_1.0/Attachment/{attachment_uuid}.file using the UUID returned in the x-record-uuid header.
For the Attachment record, related_object should be set to job, related_object_uuid should be the job UUID, and file_type should match the file extension including the leading full stop, for example .pdf.
For the .file request, the documented example posts to /Attachment/{uuid}.file and supplies the file as the file field using CurlFile.
The Attachment create endpoint requires the manage_attachments OAuth scope when using OAuth.
If requests matching that format are consistently returning 400 Invalid data format supplied in request body, that’s something we’ll need to investigate from our side rather than continue troubleshooting publicly.
Please email support@servicem8.com with a reproducible cURL example, the affected attachment UUID returned in x-record-uuid, the full response status/headers/body, and a timestamp with timezone so we can trace it.