Platform_account_provisioning returning 200 success but accounts not created

API & SDK
1

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

2

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

3

Thanks Cody,

Will do!