# SDK & API wishlist: what would help you build better experiences?

**URL:** <https://community.servicem8.com/t/sdk-api-wishlist-what-would-help-you-build-better-experiences/1128>\
**Category:** API & SDK\
**Created:** [June 22, 2026, 6:20am UTC](https://community.servicem8.com/t/sdk-api-wishlist-what-would-help-you-build-better-experiences/1128 "2026-06-22T06:20:46Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Cody](https://sea2.discourse-cdn.com/flex002/user_avatar/community.servicem8.com/cody/32/52_2.png) [@Cody](https://community.servicem8.com/u/Cody)\
**Post date:** [June 22, 2026, 6:20am UTC](https://community.servicem8.com/t/sdk-api-wishlist-what-would-help-you-build-better-experiences/1128/1 "2026-06-22T06:20:46Z")

</div>

Hi everyone,

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.

- Cody

---

<div class="post-metadata">

**Author:** ![chad\_befus](https://avatars.discourse-cdn.com/v4/letter/c/b5a626/32.png) [@chad\_befus](https://community.servicem8.com/u/chad_befus)\
**Post date:** [June 27, 2026, 6:55am UTC](https://community.servicem8.com/t/sdk-api-wishlist-what-would-help-you-build-better-experiences/1128/2 "2026-06-27T06:55:48Z")

</div>

Cody,

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.

-Chad

---

<div class="post-metadata">

**Author:** ![Cody](https://sea2.discourse-cdn.com/flex002/user_avatar/community.servicem8.com/cody/32/52_2.png) [@Cody](https://community.servicem8.com/u/Cody)\
**Post date:** [July 1, 2026, 12:20pm UTC](https://community.servicem8.com/t/sdk-api-wishlist-what-would-help-you-build-better-experiences/1128/3 "2026-07-01T12:20:45Z")

</div>

Hey Chad, quick update: this is done now. `/email.json` includes `opened`, `first_opened_at`, and `bounced` for outbound emails.

Docs are here: [List job email history](https://developer.servicem8.com/reference/listemailmessages)

---

<div class="post-metadata">

**Author:** ![chad\_befus](https://avatars.discourse-cdn.com/v4/letter/c/b5a626/32.png) [@chad\_befus](https://community.servicem8.com/u/chad_befus)\
**Post date:** [July 2, 2026, 5:42am UTC](https://community.servicem8.com/t/sdk-api-wishlist-what-would-help-you-build-better-experiences/1128/4 "2026-07-02T05:42:16Z")

</div>

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?

Thanks,

-Chad

---

<div class="post-metadata">

**Author:** ![Dan](https://avatars.discourse-cdn.com/v4/letter/d/eada6e/32.png) [@Dan](https://community.servicem8.com/u/Dan)\
**Post date:** [July 3, 2026, 12:57am UTC](https://community.servicem8.com/t/sdk-api-wishlist-what-would-help-you-build-better-experiences/1128/5 "2026-07-03T00:57:51Z")

</div>

Something I’d like to see improved regarding simple hosted function logging:

- currently the logs seam to hit a limit and new entries are no longer visible which makes debugging difficult.

For example an add-on used daily hasn’t updated the log since October 2025 which makes ongoing debugging impossible.

---

<div class="post-metadata">

**Author:** ![jason\_gebert](https://avatars.discourse-cdn.com/v4/letter/j/b782af/32.png) [@jason\_gebert](https://community.servicem8.com/u/jason_gebert)\
**Post date:** [July 3, 2026, 8:08am UTC](https://community.servicem8.com/t/sdk-api-wishlist-what-would-help-you-build-better-experiences/1128/6 "2026-07-03T08:08:54Z")

</div>

@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.

---

<div class="post-metadata">

**Author:** ![Cody](https://sea2.discourse-cdn.com/flex002/user_avatar/community.servicem8.com/cody/32/52_2.png) [@Cody](https://community.servicem8.com/u/Cody)\
**Post date:** [July 5, 2026, 5:44am UTC](https://community.servicem8.com/t/sdk-api-wishlist-what-would-help-you-build-better-experiences/1128/7 "2026-07-05T05:44:21Z")

</div>

Hi Chad,

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](mailto: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?

Thanks,  
Cody

---

<div class="post-metadata">

**Author:** ![Cody](https://sea2.discourse-cdn.com/flex002/user_avatar/community.servicem8.com/cody/32/52_2.png) [@Cody](https://community.servicem8.com/u/Cody)\
**Post date:** [July 6, 2026, 1:00am UTC](https://community.servicem8.com/t/sdk-api-wishlist-what-would-help-you-build-better-experiences/1128/8 "2026-07-06T01:00:22Z")

</div>

Hi Dan,

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](mailto:support@servicem8.com) with the add-on name/ID, approximate timestamps, and any screenshots from the Developer Portal logs view.

Thanks,  
Cody

---

<div class="post-metadata">

**Author:** ![chad\_befus](https://avatars.discourse-cdn.com/v4/letter/c/b5a626/32.png) [@chad\_befus](https://community.servicem8.com/u/chad_befus)\
**Post date:** [July 8, 2026, 4:40am UTC](https://community.servicem8.com/t/sdk-api-wishlist-what-would-help-you-build-better-experiences/1128/9 "2026-07-08T04:40:00Z")

</div>

Cody,

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!

-Chad

---

<div class="post-metadata">

**Author:** ![thibaut\_holl1](https://avatars.discourse-cdn.com/v4/letter/t/ecc23a/32.png) [@thibaut\_holl1](https://community.servicem8.com/u/thibaut_holl1)\
**Post date:** [July 9, 2026, 12:43am UTC](https://community.servicem8.com/t/sdk-api-wishlist-what-would-help-you-build-better-experiences/1128/10 "2026-07-09T00:43:42Z")

</div>

Hi Cody,

It would be great if we were able to mark job as approved using the API.i.e send completed jobs through to Xero (billing tab - awaiting approval).

---

<div class="post-metadata">

**Author:** ![Cody](https://sea2.discourse-cdn.com/flex002/user_avatar/community.servicem8.com/cody/32/52_2.png) [@Cody](https://community.servicem8.com/u/Cody)\
**Post date:** [July 12, 2026, 12:45am UTC](https://community.servicem8.com/t/sdk-api-wishlist-what-would-help-you-build-better-experiences/1128/11 "2026-07-12T00:45:56Z")

</div>

Hi Thibaut,

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.

Thanks,  
Cody

---

<div class="post-metadata">

**Author:** ![chad\_befus](https://avatars.discourse-cdn.com/v4/letter/c/b5a626/32.png) [@chad\_befus](https://community.servicem8.com/u/chad_befus)\
**Post date:** [July 13, 2026, 8:16am UTC](https://community.servicem8.com/t/sdk-api-wishlist-what-would-help-you-build-better-experiences/1128/12 "2026-07-13T08:16:32Z")

</div>

A big one for me would be a **developer sandbox**.

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.

-Chad

---

<div class="post-metadata">

**Author:** ![michael\_knight](https://sea2.discourse-cdn.com/flex002/user_avatar/community.servicem8.com/michael_knight/32/54_2.png) [@michael\_knight](https://community.servicem8.com/u/michael_knight)\
**Post date:** [July 15, 2026, 3:50am UTC](https://community.servicem8.com/t/sdk-api-wishlist-what-would-help-you-build-better-experiences/1128/13 "2026-07-15T03:50:57Z")

</div>

All you would need to do is create a new trial account and then upgrade that account as a developer account. I have multiple developer accounts.

---

<div class="post-metadata">

**Author:** ![michael\_knight](https://sea2.discourse-cdn.com/flex002/user_avatar/community.servicem8.com/michael_knight/32/54_2.png) [@michael\_knight](https://community.servicem8.com/u/michael_knight)\
**Post date:** [July 15, 2026, 3:56am UTC](https://community.servicem8.com/t/sdk-api-wishlist-what-would-help-you-build-better-experiences/1128/14 "2026-07-15T03:56:39Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![michael\_knight](https://sea2.discourse-cdn.com/flex002/user_avatar/community.servicem8.com/michael_knight/32/54_2.png) [@michael\_knight](https://community.servicem8.com/u/michael_knight)\
**Post date:** [July 15, 2026, 4:26am UTC](https://community.servicem8.com/t/sdk-api-wishlist-what-would-help-you-build-better-experiences/1128/15 "2026-07-15T04:26:31Z")

</div>

It would be great to have more webhook endpoints available for the object webhooks

Eg  
jobmaterial  
Would benefit integrations for stock management and pricing reporting

jobmaterialbundle  
Same as above

companycontacts  
Would benefit crm integrations ensuring sync

assets  
Notified when assets are created or edited

jobllocation  
job activities are currently available but not job allocations

Staff  
for adding staff to onboarding and training platforms

It would also be great to improve some event webhooks  
Events like  
Job Scheduled  
Job Allocation

And Improvement to receiving duplicate conflicting webhooks where a particular webhook takes priority

A prime example of this EG  
If you are subscribed to job.created & job.status\_changed to monitor both new and completed changes

When you create a new job it will fire both webhooks. it should only really fire the new job hook.

---

<div class="post-metadata">

**Author:** ![chad\_befus](https://avatars.discourse-cdn.com/v4/letter/c/b5a626/32.png) [@chad\_befus](https://community.servicem8.com/u/chad_befus)\
**Post date:** [July 15, 2026, 5:19am UTC](https://community.servicem8.com/t/sdk-api-wishlist-what-would-help-you-build-better-experiences/1128/16 "2026-07-15T05:19:41Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Cody](https://sea2.discourse-cdn.com/flex002/user_avatar/community.servicem8.com/cody/32/52_2.png) [@Cody](https://community.servicem8.com/u/Cody)\
**Post date:** [July 16, 2026, 8:17am UTC](https://community.servicem8.com/t/sdk-api-wishlist-what-would-help-you-build-better-experiences/1128/17 "2026-07-16T08:17:13Z")

</div>

Hi Chad,

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.

Thanks,  
Cody

---

<div class="post-metadata">

**Author:** ![Cody](https://sea2.discourse-cdn.com/flex002/user_avatar/community.servicem8.com/cody/32/52_2.png) [@Cody](https://community.servicem8.com/u/Cody)\
**Post date:** [July 18, 2026, 3:51am UTC](https://community.servicem8.com/t/sdk-api-wishlist-what-would-help-you-build-better-experiences/1128/18 "2026-07-18T03:51:56Z")

</div>

Hi Michael,

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.

Thanks,  
Cody

---

<div class="post-metadata">

**Author:** ![Cody](https://sea2.discourse-cdn.com/flex002/user_avatar/community.servicem8.com/cody/32/52_2.png) [@Cody](https://community.servicem8.com/u/Cody)\
**Post date:** [July 18, 2026, 3:57am UTC](https://community.servicem8.com/t/sdk-api-wishlist-what-would-help-you-build-better-experiences/1128/19 "2026-07-18T03:57:27Z")

</div>

Hi Michael,

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.

Thanks,  
Cody

---

<div class="post-metadata">

**Author:** ![Cody](https://sea2.discourse-cdn.com/flex002/user_avatar/community.servicem8.com/cody/32/52_2.png) [@Cody](https://community.servicem8.com/u/Cody)\
**Post date:** [July 18, 2026, 4:27am UTC](https://community.servicem8.com/t/sdk-api-wishlist-what-would-help-you-build-better-experiences/1128/20 "2026-07-18T04:27:08Z")

</div>

Hi Michael,

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.

Thanks,  
Cody

[Next page](https://community.servicem8.com/t/sdk-api-wishlist-what-would-help-you-build-better-experiences/1128.md?page=2)
