Staffmessage POST with x-impersonate-uuid returns 200 + x-record-uuid but the record 404s

Developer General
1

Add-on (OAuth 2.0). Creating a staff message as a specific staff member via x-impersonate-uuid, the create reports success and delivers to Team Chat, but the resulting record cannot be retrieved — including in your own API tooling.

Request:

POST /api_1.0/staffmessage.json
Headers: Authorization: Bearer <token>,  x-impersonate-uuid: <sending staff uuid>
Body: { "uuid": "9129f32f-beb0-4e44-b2c9-3efddfd3c625",
        "from_staff_uuid": "<sending staff>", "to_staff_uuid": "<recipient>",
        "message": "…", "regarding_job_uuid": "<job>" }

Response: 200 → {"errorCode": 0, "message": "OK"}, with x-record-uuid: 9129f32f-… (the UUID I supplied). The recipient does receive it in Team Chat, correctly attributed to the impersonated sender.

But the record is not retrievable:

GET /api_1.0/staffmessage/9129f32f-beb0-4e44-b2c9-3efddfd3c625.json  →  404 Record Not Found

Confirmed 404 both from my integration and from the ServiceM8 API tooling directly. It also never appears in any list query or account sync. Without impersonation (creating as the connection’s own staff), the record does persist and reads back normally.

Questions:

  1. Is it expected that an impersonated staffmessage create returns 200 + an x-record-uuid that resolves to 404? That seems contradictory — success implies a retrievable record.
  2. Is there a supported way to create a staff message that is both attributed to the actual staff member and persisted/queryable (so we can link it to a job / reconcile it)?
  3. Is x-impersonate-uuid intended for staffmessage at all, or only the Messaging API?
2

Hi Miciah,

This doesn’t match the documented REST API behaviour. A successful staff-message POST should return the UUID of the newly created Staff Message record, while a 404 from the retrieve endpoint means the record doesn’t exist or has been deleted.

x-impersonate-uuid is supported for OAuth GET, POST, PUT and DELETE requests, and the documentation specifically uses a staff messaging app posting on behalf of the authenticated user as an example. It isn’t documented as being limited to the separate Messaging API.

The documented method for your use case is the one you’re already using: POST to /staffmessage.json with from_staff_uuid, to_staff_uuid, message and, where required, regarding_job_uuid. We don’t have a documented alternative that would explain or avoid the successful delivery followed by a missing record.

This will need an account-specific investigation. Email support@servicem8.com with the add-on ID, affected account UUID, UTC request time, returned x-record-uuid, sender and recipient UUIDs, and redacted request and response details, including whether the follow-up GET and list requests used impersonation. Don’t include the OAuth token or app secret publicly.

Thanks,
Cody