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

**URL:** <https://community.servicem8.com/t/staffmessage-post-with-x-impersonate-uuid-returns-200-x-record-uuid-but-the-record-404s/1209>\
**Category:** General\
**Created:** [September 29, 2026, 7:15am UTC](https://community.servicem8.com/t/staffmessage-post-with-x-impersonate-uuid-returns-200-x-record-uuid-but-the-record-404s/1209 "2026-09-29T07:15:07Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![miciah\_stamates](https://avatars.discourse-cdn.com/v4/letter/m/ed655f/32.png) [@miciah\_stamates](https://community.servicem8.com/u/miciah_stamates)\
**Post date:** [September 29, 2026, 7:15am UTC](https://community.servicem8.com/t/staffmessage-post-with-x-impersonate-uuid-returns-200-x-record-uuid-but-the-record-404s/1209/1 "2026-09-29T07:15:07Z")

</div>

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:

```auto
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:

```auto
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?

---

<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:** [October 2, 2026, 7:16am UTC](https://community.servicem8.com/t/staffmessage-post-with-x-impersonate-uuid-returns-200-x-record-uuid-but-the-record-404s/1209/2 "2026-10-02T07:16:36Z")

</div>

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