LinkedIn
Decision-gated
LinkedIn engineering guide

Why a bulk InMail endpoint is the wrong product boundary

A risk-focused guide for replacing bulk dispatch with reviewed, entitlement-aware individual commands and measurable stop controls.

Educational research only. LinkedIn account access remains decision-gated. No DewEngine LinkedIn connector is approved or implemented.
01
Reframe the request

Bulk is a planning concern, not one provider action

A bulk endpoint hides the sender, recipient-specific eligibility, approval, budget, and outcome behind one request. For sensitive professional outreach, each message must stand on its own. DewEngine does not offer a LinkedIn or InMail connector, and it will not enable unauthorized bulk automation. The lawful access, provider authorization, and product-risk gates remain closed before any implementation discussion.

  • Turn a batch into reviewable individual candidates
  • Keep the entire workflow valuable as a draft or export if sending is unavailable
02
Audience construction

Prove why every recipient belongs

A query or imported list can contain duplicates, wrong identities, existing customers, prior declines, and people owned by another team. Build a frozen recipient snapshot with source, purpose, match evidence, suppression result, relationship context, and responsible user. Do not expand an audience from inferred sensitive traits or assume professional visibility equals willingness to receive a message.

  • Review exclusions and duplicates before composition
  • Store the audience version used for each approval
03
Personalization

Use context to prevent mistakes, not manufacture familiarity

Personalization should be factual, minimal, and visible to the sender. Render every recipient's final content and flag missing or contradictory variables. A shared template approval cannot cover fabricated employer names or unsupported claims. For higher-risk campaigns, sample review is not enough; the acting user needs a meaningful way to inspect and exclude individual messages.

  • Reject unresolved placeholders and unverified derived facts
  • Bind approval to each final recipient-content pair
04
Scheduler

Use admission control rather than a blast loop

Each eligible item becomes a durable command only when account health, product entitlement, customer policy, budget, and kill switch allow it. Atomic reservations prevent parallel workers from exceeding internal limits. Provider feedback can reduce or stop the queue. Randomized timing meant to evade enforcement is prohibited; transparent pacing and small batches make outcomes inspectable and reversible.

  • Re-evaluate eligibility just before every attempt
  • Stop remaining commands after restriction or policy change
05
Outcome accounting

Never summarize uncertainty as sent

A campaign view should count approved, attempted, acknowledged, rejected, indeterminate, replied, and manually cancelled separately. One provider response cannot prove recipient delivery or interest. A timeout after dispatch stays indeterminate until an approved read path reconciles it. Batch retries must select only definitely unattempted items, preserving idempotency across worker crashes and operator restarts.

  • Report item-level evidence before aggregate rates
  • Pause follow-ups on replies and unknown prior outcomes
06
Go/no-go

Require entitlement and abuse-resistance evidence

Release would require counsel approval, provider authorization, exact account-product eligibility, trustworthy credit behavior, consented real-account tests, suppression, purpose controls, audit, conservative budgets, restriction handling, deletion, and a global kill switch. The system must show that it can refuse unsafe volume. Until then, teams should use the guide to design review and governance, not to dispatch LinkedIn InMails.

  • Fault-test concurrent budget reservation and lost responses
  • Document the non-sending customer workflow
Questions

Before you build.

Why not expose one API call with an array of InMail recipients?+

It obscures individual eligibility, approval, idempotency, and outcomes. A batch coordinator may organize work, but each recipient needs a separate durable command and a truthful result that can be stopped or reconciled independently.

Can random delays make bulk InMail acceptable?+

No. Timing camouflage does not create authorization, consent, or a lawful purpose. DewEngine explicitly rejects evasion and human-mimicry mechanisms; a permitted workflow would rely on clear rules, conservative budgets, and user control.

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