01
Capability honesty
A voice-message API needs more than message.send
A production surface needs media creation, upload, association, retrieval or playback metadata, status, and deletion semantics. DewEngine's LinkedIn catalog does not declare audio, attachments, upload, or voice-specific events. The provider itself remains decision-gated. This route therefore documents a possible resource lifecycle and cannot be used as evidence that audio messages are supported.
- Keep the capability absent until its full lifecycle is proven
- Do not expose a text method with an undocumented media field
02
Draft resource
Give recorded audio explicit ownership and expiry
A draft should carry workspace, acting account, target conversation, creator, codec, duration, checksum, creation time, and expiry. Store bytes in encrypted object storage rather than database logs or event payloads. A user can preview, replace, or delete the recording before approval. Changing the recipient or sender should invalidate the existing authorization even when the audio stays identical.
- Reject cross-tenant object references
- Clean abandoned recordings through a verified retention job
03
Derived content
Treat transcripts as fallible personal data
Speech-to-text can improve review and accessibility, but the transcript is a derived interpretation. Record its model or process version, language, confidence where useful, and human corrections. Do not expose it to broad search or analytics by default. Deleting audio should apply the documented policy to transcript, waveform, preview, and cached derivatives rather than leave a hidden text copy.
- Let users correct or discard a transcript
- Do not use voice content for unrelated model training
04
Send state
Track upload and message acknowledgement separately
An external upload can succeed while message creation fails, or a response can disappear after either action. Persist attempts before dispatch and distinguish definitely unattempted, acknowledged, failed, and indeterminate states. Idempotency must bind the approved audio hash and conversation. Reconciliation may use an authorized read contract if available; otherwise an operator reviews ambiguity before any repeat.
- Never replace an approved object during retry
- Garbage-collect orphan uploads only when outcome rules permit
05
Receiver experience
Plan playback, context, and fallback explicitly
The customer UI should show sender, duration, timestamp, accessible playback controls, and source status without claiming a provider read or delivery state it cannot observe. Downloads and forwarding need role checks. If an account or client does not support voice, return an explicit capability error and let the sender choose text; silently transcribing and sending changes the message.
- Expose unsupported playback or download states
- Keep a user-chosen text alternative separate from the recording
06
Evidence matrix
Qualify bytes, metadata, and lifecycle together
After legal and provider approval, tests would need exact eligible products, codecs, sizes, duration, malformed files, interruption, duplicate upload, ambiguous send, account restriction, object isolation, playback authorization, transcript handling, retention, export, deletion, and kill-switch coverage. Consented real-account conformance must support every advertised behavior. Without it, voice messaging stays outside DewEngine's LinkedIn manifest.
- Test deletion after partial and successful dispatch
- Keep media content out of webhook diagnostics