ServiceM8 API Updates - May 2026

General
1

May adds new REST API resources for service templates and job communication history, plus webhook diagnostics improvements for API integrations.

New: ServiceTemplate API

A new ServiceTemplate REST resource is available for accounts using Services:

  • GET /api_1.0/ServiceTemplate.json
  • GET /api_1.0/ServiceTemplate/{uuid}.json
  • POST /api_1.0/ServiceTemplate/{uuid}.json
  • DELETE /api_1.0/ServiceTemplate/{uuid}.json

The API returns a curated service template shape including questions, choices, variations, and staff capabilities. Reads require read_service_templates; create/update/delete requires manage_service_templates.

POST performs sparse updates on editable service rows only. Publishing via the API is not supported in this version. DELETE soft-deletes the service.

New: Job SMS And Email History

Two new read-only resources expose job-related communication history:

  • GET /api_1.0/sms.json
  • GET /api_1.0/sms/{uuid}.json
  • GET /api_1.0/email.json
  • GET /api_1.0/email/{uuid}.json

The SMS API requires read_sms; the Email API requires read_email.

Both resources return merged inbound and outbound job history, support cursor pagination via x-next-cursor, and support $filter for direction, related_object, and related_object_uuid.

Use $filter, for example:

/api_1.0/sms.json?$filter=direction eq inbound and related_object_uuid eq {job_uuid}

Direct query filters such as ?direction=inbound are not supported for these endpoints.

Webhook Subscription Diagnostics

GET /webhook_subscriptions now supports:

status=active
status=inactive
status=all

Responses include last_failure_reason and last_failure_at, making it easier to diagnose subscriptions that were automatically deactivated after repeated delivery failures.

Webhook documentation now also clarifies that callback URLs must return a successful 2xx response within 10 seconds. Repeated failures or timeouts can cause automatic deactivation.

3 Likes
SMS / Email read only api
3

Hello.
Thanks for the update.

When I call the SMS path, I get this error:
{
“errorCode”: 400,
“message”: “sms is not an authorised object type”,
“documentation”: “Please refer to ``https://developer.servicem8.com/llms.txt`` for developer documentation.”
}

This happens to all of the new paths in this update.

I have set the correct scope for all of them.

4

Hi Chris,

That “sms is not an authorised object type” error means the May 2026 API update hasn’t rolled out to your account yet.

If you log a Support ticket via the Help menu in the Online Dashboard, our team can prioritise the rollout to your account.

Also, don’t post any API keys/tokens/app secrets publicly.

Thanks,
Cody

1 Like
5

Hi Cody,

This is great thanks. I’ve emailed support for the read email and sms and the read service templates but they advised only read sms and email available. I did link this and the other thread. Any idea when we will have access to the service template?

Also is there any chance of getting a sent by staff UUID in the outbound endpoints for sms and email?

1 Like
6

Hi Jason,

At the moment, what our Support team can enable via the current private preview is limited to the new read-only SMS and Email endpoints, and it doesn’t include ServiceTemplate access yet.

On the scopes side, Support have confirmed read_sms isn’t a valid OAuth scope right now, and advised using read_inbox for reading SMS/email message data via the API.

It’s best to reply to your Support email and ask to be included in the ServiceTemplate API preview as soon as it becomes available.

Thanks,
Cody

7

Didn’t have a lot of luck with this request via support but still trying…

-Chad

8

Hi Cody,
No worries, is there any chance of getting a sent by staff UUID in the outbound endpoints for sms and email ?

9

Hi Jason,

Good news, we’re rolling out an update to the endpoint to include sent_by_staff_uuid.

Thanks,
Cody

10

Thanks Cody,

Is there also a way we can “reply to” based on read_email. So we aren’t sending new emails each time?
The read side — expose the RFC Message-ID header on /email.json rows (so we have something to thread against)

The send side — accept an inReplyTo parameter on platform_service_email (so the outgoing email carries proper In-Reply-To / References headers)

11

Hi Jason,

At the moment there isn’t a documented way to send a true “reply” email (with RFC threading headers like In-Reply-To / References) via POST /platform_service_email because the request schema supports replyTo but doesn’t include an inReplyTo (or similar) parameter.

If you’d like Message-ID exposed on the read side and an inReplyTo parameter supported on the send side, the best path is to email that as a feature suggestion to support@servicem8.com (including example payloads/field names).

Thanks,
Cody

12

Hey Cody,

Do you know when these will be available?
A new ServiceTemplate REST resource is available for accounts using Services:

  • GET /api_1.0/ServiceTemplate.json

  • GET /api_1.0/ServiceTemplate/{uuid}.json

  • POST /api_1.0/ServiceTemplate/{uuid}.json

  • DELETE /api_1.0/ServiceTemplate/{uuid}.json

13

Hi Cody.
Just wondering if there is pagination for the Email list path /api_1.0/email.json ?

I’ve tried using the usual pagination method (cursor = ‘-1’) but no luck.

It works on the new path /api_1.0/sms.json

If the email path has pagination, is it done differently?

Also, it would be nice to have a field for email_has_been_opened for the new email paths?

Cheers :slight_smile:

14

Hi Chris,

Where an API list endpoint supports pagination, it uses cursor-based pagination via a cursor query param and the x-next-cursor response header (rather than just cursor=-1 on its own).

What to try:

  1. First page: GET /api_1.0/sms.json?cursor=-1 (or /api_1.0/email.json?cursor=-1).
  2. Check the response headers for x-next-cursor and, if it’s present, call the next page using that value: GET /api_1.0/sms.json?cursor={x-next-cursor}.
  3. When you reach the last page, x-next-cursor will be absent.

If you’re also filtering, $filter can be combined with pagination like ...?$filter=...&cursor=-1 (note the &cursor=-1).

Once you’ve tried that, if you’re still not seeing an x-next-cursor header when you expect more data, email support@servicem8.com with an example request and the response headers so we can check what’s happening on your account.

Thanks,
Cody