Do Phone webhooks fire for call-queue-owned recordings? (user-managed app)

Our org records outbound calls via automatic recording on a call queue, so
every recording is owned by the queue, not a user. GET /v2/phone/users/me/recordings
returns "owner": { "type": "callQueue" } for all of them, with no user_id
field. The authorizing user is on that queue’s recording access member list.

Q1. Does phone.recording_completed_for_access_member fire in this case?

Or does it only fire for recordings owned by a user who granted access to
others? If it doesn’t fire here, what is the correct event / scope / app type
for an app that needs queue-owned recordings its user can access?

Q2. If it does fire, is payload.object.recordings[].user_id present?

Our integration resolves the owner from that field, and it is absent in the REST
response. Knowing this before we build would save a redesign.

Already verified

  • Non-Phone events arrive; Phone events never have. Same app, same endpoint.
    A user.updated was delivered and answered HTTP 200, arriving 193 ms
    after the payload timestamp. So the endpoint works. (We did have a WAF problem
    on our side — found and fixed, and proven fixed by the above.)
  • All 68 Phone events are subscribed and still nothing arrives, including
    recording-independent ones like phone.caller_ringing. Re-authorizing the app
    changed nothing.
  • The calls and recordings exist — both appear in call_logs and
    recordings, with transcript URLs.
  • Scopes granted: user:read:user, phone:read:list_call_logs,
    phone:read:list_recordings. If Phone webhooks need more, that would explain
    it, but I couldn’t find that documented.

Note: the Marketplace webhook logs page shows nothing for this app — not even
the user.updated I can prove arrived — so it can’t be used as evidence either
way. (API Call Logs works fine.)

I can’t test the alternative: outbound calling from the personal extension is
disabled by org policy, and queue-level automatic recording is an org-wide
security requirement. So every recording this account can produce is
queue-owned — meaning if these events exclude queue-owned recordings, that’s a
hard blocker for us, not a test artifact.

Thanks in advance.