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.”
account_uuid ismissing from the response entirely. Your docs specify this field should contain the vendor UUID of the newly provisioned account.
account_url pointstoaninternalpage (PluginMultipleDatabases_WaitForDatabaseCreation) rather than an auto-signin URL as documented. This URL does not load a functional account.
success isaboolean (true) rather than a number (1) as documented.
Verificationthataccountswerenotcreated:
Navigating to the returned account_url does not sign into any account
Thiswasreproducedacrosstwoseparateprovisioningattempts with different email addresses, both returning the same response structure and non-functional URLs.
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.
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.
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.
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.