We’re gathering input from developers to help shape future improvements to the ServiceM8 SDK and API.
If there’s a feature, endpoint, extension point, or improvement you’d like to see, please share:
What you’d like
Why it would be useful or important
How you’d use it in your add-on or integration
We’re especially interested in ideas around billing and payments, logging, debugging, visibility, performance, customer experience, additional places in ServiceM8 where add-ons could extend the product, and expanded API capabilities.
Rough ideas and specific examples are both welcome. Thanks for taking the time to share what would help you build better experiences for ServiceM8 customers.
Here’s a small quick one — the new email-in-diary functionality is great, but the “opened at {date time}” info the diary shows doesn’t appear to be exposed via the API: the /email.json record has no opened/read field, and there’s no email.opened webhook.
Being able to automate a check for whether an email was opened would be extremely valuable — e.g. confirming a customer actually saw a booking/confirmation email. A field on the email record (opened / first_opened_at) or an email.opened event would do it. Delivered/bounced status would be a nice bonus.
Cody — thanks for the fast turnaround on this! One thing: the docs are live but our account still returns the old record shape from /email.json — no opened / first_opened_at / bounced fields at all, even on a fresh email test I sent a few minutes ago.
Will the roll out take a bit, or does it need per account enabling like the history API did?
@Cody Tasks used to have a webhook but since these have now changed to checklists assigned to staff would be good to get the webhook on creation / completion for a checklist when assigned to a staff UUID?
Would also love webhooks for email / sms in and out as well if possible.
No extra query parameter should be needed for the normal /email.json request: the developer docs list it as the List job email history endpoint, with cursor, limit, and $filter as the documented query params.
Given your account can hit /email.json but the new fields aren’t present, this is something we’ll need to check against your account privately. We’ve had recent API email endpoint rollout cases handled by enabling the endpoint/update on the account, then having the user log out and back in.
Can you email support@servicem8.com with your account details and a sample response showing the missing fields so we can check the rollout state for your account?
Good callout. For Simple Function Add-ons, ServiceM8 manages the infrastructure, so better log retention and clearer visibility in Function Event Logs is useful feedback for debugging hosted functions.
We’ll add this to the SDK/API wishlist, particularly the need for newer entries to remain visible rather than logs appearing capped or stale. ServiceM8 product feedback is read, analysed, and categorised by our team, but we generally won’t comment on if or when a change might be released.
For the add-on that hasn’t shown new logs since October 2025, that’s best checked privately because it may need investigation against the specific add-on. Email support@servicem8.com with the add-on name/ID, approximate timestamps, and any screenshots from the Developer Portal logs view.
Hadn’t checked in a few days so figured I’d try again before contacting support. Looks like my system detected the fields about 7 hours ago so it just took a few days to cycle through for whatever reason. All good now, thanks again!
Good suggestion. At the moment, ServiceM8 doesn’t have a documented API endpoint/action to approve a completed job or invoice from Awaiting Approval, or trigger the Xero approval/sync via the API.
The current supported workflow is that completed jobs appear in Invoicing > Awaiting Approval, and approving the invoice from the Invoicing page sends it to Xero.
We’ll add an API-based “approve/send to accounting package” action to the SDK/API wishlist.
I run ServiceM8 for my fireplace company — I’m not a software business. Most of what I build is for in-house use, but a few of the tools I’ve made or am making would likely to be useful to others, and two barriers stop me from publishing them:
1. There’s nowhere safe to test. My only account is my live production account. Spinning up throwaway trial accounts isn’t a workable substitute — they’re empty, they expire, and rebuilding test data is annoying, and my staff get very confused. Creating temporary / trial accounts is an inefficient and time consuming ask that requires a lot of spare e-mail addresses - it’s all very clumsy, and frankly I have better things to do.
2. The publisher identity is wrong. Shipping an app to the ServiceM8 store under the name of my fireplace company is strange for everyone — for me, and for a customer reading the listing.
What would fix both: a developer branch account with a real sandbox — a persistent test company, a separate developer/publisher name from my operating company, and some data tools to pre-populate it (sample clients, jobs, materials, forms) so an app can be exercised end-to-end before it goes anywhere near a live account.
It would be awesome to have a recurring Jobs Endpoint
I’m assuming it hasn’t been done yet due to complexity. With services, templates involved etc
It would be useful in bringing customers from other platform over to Servicem8 who have hundred to thousands of recurring jobs in their old system, and have to manually recreate them
One more, it would be great if it were possible to POST Multiple entry arrays instead of 1 at a time. Even if it was a small limit of 50 or 100.
For the recurring jobs, big +1. Since recurring jobs are built on services, I expect this would also need fuller service-template API access. The May ServiceTemplate API is a good start on this, and both these items are near the top of my wish list also.
For the webhooks, good list; +1 in particular for jobmaterial, companycontact, asset, and joballocation object webhooks.
Jobmaterialbundle and staff aren’t a huge deal for me personally, but the rest would help significantly.
For the creation/change issue, we just need the flags set at creation to not count as a “change”. On a related note the duplicate webhook re-deliveries being sorted out would also be nice.
However, I’d also add a request for a reliability layer. I’ve seen several posts and had similar issues myself with webhook subscriptions just suddenly, silently deactivating. I’ve had to add my own layer that does a scheduled poll to flag me if this happens. If we can’t rely on the subscriptions, it really devalues the functionality they offer.
This is strong feedback, and the use case is clear. The current documented flow is to sign up for a ServiceM8 Developer account, create an add-on from the Developer menu, activate it on your own account for development and testing, and use the Private Add-on Install URL before approval, so a persistent sandbox would be a meaningful improvement for developers who don’t want to test against a live operating account.
We’ll add a developer sandbox to the SDK/API wishlist, including the ideas you called out: a persistent test company, sample data/tools for end-to-end testing, and clearer separation between an operating business and a developer or publisher identity. Product feedback is read, analysed, and categorised by our team to help shape future ServiceM8 improvements, though we generally won’t comment on if or when a specific change might be released.
That’s the closest current approach: for public-app, OAuth, or SDK work, the documented path is to register as a Development Partner, sign in, open the Developer link, and add an item to create the add-on. A custom add-on can then be activated on your own account for development and testing before it’s submitted or made publicly visible.
For private one-off integrations, the API key path doesn’t require a ServiceM8 Developer account.
Chad’s broader sandbox idea is still useful feedback, since it’s asking for a purpose-built test environment rather than only using a separate account, so we’ll keep that on the SDK/API wishlist.
Good suggestion. The current documented API endpoint is for creating individual jobs via POST /job.json, while recurring jobs are currently documented as being created online from the Dispatch Board.
You’re right that there are a few moving parts: recurring jobs are based on Job Templates, or a Service when the Services Add-on is being used, and they can automatically create, schedule, or allocate future jobs based on the recurring settings.
We’ll add a Recurring Jobs endpoint for migrations and bulk setup to the SDK/API wishlist. As with other feature feedback, product feedback is read, analysed, and categorised by our team, but we generally won’t comment on if or when a change might be released.
Good suggestions. The current Webhooks overview lists the supported object webhook objects/endpoints as Job Activity, Job, Job Payment, Note, Task, Material, Company, Attachment, and Form Response, so we’ll add the extra objects you’ve listed, including job material, job material bundle, company contact, asset, job allocation, and staff, to the SDK/API wishlist.
For event webhooks, the current Webhooks API reference lists supported event names including job.created, job.status_changed, job.updated, and other job events, but it doesn’t list separate job.scheduled or job allocation events.
We’ll also capture the feedback about event priority and reducing duplicate or conflicting webhook handling when multiple subscriptions can be triggered by the same user action.