Define a video-message command only after the LinkedIn gate clears

This research route describes the product decisions around sending video in a LinkedIn conversation. No payload, upload flow, or provider behavior is implemented or authorized today.

Decision gate closed. This access path is neither approved nor implemented; no provider action is available.

Talk to us ↗Read technical guides →

Capability boundary

Video sending is an unevidenced LinkedIn target

The catalog declares only a general target message.send action. It does not establish a video upload endpoint, supported formats, size limits, delivery semantics, or an approved account access path.

Catalog status and access: LinkedIn account products — decision gated, non official session
Authentication: Any future command would use the exact user-owned LinkedIn account authorized for the conversation, subject to the same provider/product and legal gate as the parent connector.
Resources: chats, messages
Target actions: message.send
Target events: message.received, message.sent, account.status
Limitations and failures: No video-specific method is declared; Formats, upload lifecycle, and limits are unknown until authorized provider conformance; A send acknowledgement would not prove playback, delivery, or viewing
Release gates: LinkedIn account products — Qualified legal review and provider/product authorization are required before implementation or sale

User intent

Separate an uploaded video from a pasted link

A product must decide whether the user is attaching provider-hosted media, referencing an external URL, or sending a previously uploaded asset. Those paths need different validation and cannot be represented by an invented universal video field.

Conversation target

Resolve the chat before preparing media

The command should identify the connected account and provider conversation first. Recipient guesses or cross-account conversation IDs must fail before any potentially expensive upload or state-changing provider request begins.

Media lifecycle

Treat upload and message creation as separate outcomes

If an authorized provider path later requires an upload, DewEngine must record whether the asset was accepted, expired, rejected, or attached to a message. A completed upload alone cannot be reported as a sent conversation item.

Failure handling

Do not blindly retry an uncertain media send

Timeouts can occur before or after provider acceptance. The design needs a durable content hash, command key, and reconciliation strategy before retrying, especially when the provider lacks a safe idempotency primitive.

Product safeguards

Validate purpose, pacing, and human review

Video can amplify both value and unwanted outreach. The calling product remains responsible for approval, recipient context, suppression, content policy, and pacing even if the connector eventually exposes the action.

Decision-gated contract

Review the policy boundary before implementation.

This shape documents a blocked product boundary. Legal, provider, and product-risk gates must clear before implementation or sale; it is not callable.

Explicit connected-account ownership
Stable public resource identifiers
Truthful provider outcome state
Release status beside every capability

Illustrative shapeDecision-gated · not callable

const unreleasedContract = {
  resource: "message",
  account_id: "acc_example",
  provider: "target_provider",
  availability: "not_implemented"
} as const;

No approved connector · no provider request

Questions

Before you build.

Can DewEngine send LinkedIn video messages today?+

No. This is a decision-gated design brief with no video-specific capability or provider evidence.

Is a successful upload the same as a sent message?+

No. Upload acceptance, message creation, provider acknowledgement, and any later delivery evidence are distinct states.

Build with us

Does this match the workflow your users need?

DewEngine is in development. Real use cases decide what ships first.

Share your use case ↗