Platform_account_provisioning returning 200 success but accounts not created

Endpoint: POST https://api.servicem8.com/platform_account_provisioning

Authentication: OAuth2 Bearer token from a Partner-activated account

Issue: The endpoint returns HTTP 200 with success: true, but the provisioned accounts do not exist. The account_url does not work, and password reset for the provisioned email returns “Invalid Email Address.”

Request payload sent:
{
“country”: “US”,
“demo”: 1,
“business_name”: “Dunder Mifflin”,
“email”: “demo20250515@dddesigned.com”,
“contact_name”: “Michael Scott”
}

Response received (HTTP 200):
{
“success”: true,
“account_type”: “Demo”,
“account_url”: " Smart Job Management Software | ServiceM8™ "
}

Expected response per your API documentation:
{
“success”: 1,
“account_type”: “Demo”,
“account_uuid”: “”,
“account_url”: “”
}

Discrepancies from documented behavior:

  1. account_uuid is missing from the response entirely. Your docs specify this field should contain the vendor UUID of the newly provisioned account.
  2. account_url points to an internal page (PluginMultipleDatabases_WaitForDatabaseCreation) rather than an auto-signin URL as documented. This URL does not load a functional account.
  3. success is a boolean (true) rather than a number (1) as documented.

Verification that accounts were not created:

This was reproduced across two separate provisioning attempts with different email addresses, both returning the same response structure and non-functional URLs.

Reference: Provision a new ServiceM8 account

Hi Miciah,

Our published docs for POST /platform_account_provisioning describe this endpoint as creating a new ServiceM8 account, and note that provisioning can only be done by a ServiceM8 Partner account.

The documented 200 response schema includes account_uuid (the vendor UUID of the provisioned account) and an account_url that automatically signs in to the newly provisioned account.

So a 200 response that omits account_uuid and returns a non-functional account_url doesn’t match the published behavior, and we’ll need to trace what happened on our side against the exact request.

Email support@servicem8.com with the timestamp(s) of a failing call plus the full request/response (with any API keys/tokens removed) and we can investigate it in the logs.

Thanks,
Cody

Thanks Cody,

Will do!

Hey Miciah - did this get resolved as I’m seeing the same thing

Hey Franco,

Honestly no. I got wrapped up in project after project and have not returned to try and get this sorted.

It would be rely handy to have working, be it for testing or for actual client works (ie franchises and alike). Hopefully at some point soon, but it you figure it out, I’d love to hear about it.

Hi Franco,

We can’t confirm Miciah’s support case publicly, but the published docs for POST /platform_account_provisioning still describe it as an endpoint for ServiceM8 Partners to create new ServiceM8 accounts.

Those docs also show a successful response should include account_uuid, described as the Vendor UUID of the provisioned account, and account_url, described as a URL that automatically signs in to the newly provisioned account.

If you’re getting a 200/success response without account_uuid or with a non-functional account_url, that doesn’t match the documented response, and ServiceM8 Support is the right place for troubleshooting help.

Email support@servicem8.com with the failing call timestamp(s) and the full request/response, with any access tokens or app secrets removed before sending.

Thanks,
Cody

Hi Miciah and Franco,

There isn’t a public workaround we can suggest here. The published docs say POST /platform_account_provisioning is used to create a new ServiceM8 account, and that account provisioning can only be done by a ServiceM8 Partner account.

The documented success response includes account_uuid as the vendor UUID of the provisioned account, and account_url as a URL that automatically signs in to the newly provisioned account.

If you’re getting a 200 success response without account_uuid, or a URL that doesn’t open the provisioned account, we’ll need Support to investigate the specific API calls privately. Email support@servicem8.com with the timestamp of a recent failing call and the full request/response, with any tokens or secrets removed.

Thanks,
Cody