Integrate invitation proposals into an application responsibly

An application-facing design for recipient selection, account ownership, approval, durable commands, relationship outcomes, and provider-risk controls.

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

Talk to us ↗Read technical guides →

UI contract

Expose a proposal before any action

The host application can present a possible invitation with the intended professional account, recipient, purpose, relationship context, and optional note if an approved contract supports one. It should not call a hidden send action when a user saves a contact. DewEngine's invitation target is unimplemented and decision-gated, so the control remains disabled unless capability discovery later proves eligibility.

Use a deliberate review screen, not a preselected checkbox
Keep record creation independent from provider action

Account mapping

Bind the application's user to the acting account

A backend API key identifies the customer application, not the person whose professional account would send. Map the authenticated app user to an owned or delegated connected account and enforce role changes. The recipient reference must belong to the same authorized provider context. Reject guessed IDs, cross-tenant account references, and stale mappings after employee departure.

Show the sender identity in every confirmation
Audit delegation and account reassignment

Eligibility

Recheck relation and suppression state

A recipient may already be connected, have a pending request, be suppressed, or have a recent conversation owned by another teammate. Query the customer system and any approved provider projection immediately before creating the command. Unknown or stale relation state should block or request review. A search result alone never authorizes an invitation.

Deduplicate per acting account and recipient
Cancel queued proposals after manual relationship changes

Command API

Return a durable state instead of instant success

The application supplies a unique idempotency key and receives an opaque command ID. Policy approval, budget reservation, dispatch attempt, provider acknowledgement, rejection, and indeterminate outcome remain distinct. A network timeout after possible dispatch is not safe to retry. If an approved read contract can reconcile pending relation state, record that evidence before changing the outcome.

Make client retries return the original command
Do not claim relation acceptance at send time

Event handoff

Translate acceptance only from observed evidence

If relation.accepted becomes an approved event, deliver it through a tenant-scoped signed webhook with stable identity and deduplication. The application can update research context or notify the owner, but acceptance should not trigger an automatic pitch. Late, duplicated, or reordered events must not reopen cancelled sequences or attach a relation to the wrong CRM contact.

Make webhook handlers idempotent
Retain the match evidence between relation and customer record

Release qualification

Prove control across app, connector, and provider

Acceptance requires legal and provider authorization, account-product eligibility, host-user delegation tests, cross-tenant substitution, duplicate and concurrent requests, stale approvals, throttling, restriction, reconnect, ambiguous outcomes, acceptance events, retention, deletion, budgets, and kill switches. The app should degrade to a research or manual task when capability is absent. No API client should imply otherwise.

Test role revocation between approval and dispatch
Verify the kill switch cancels outstanding eligible work

Questions

Before you build.

Should saving a prospect in an app also send an invitation?+

No. Saving is an internal reversible action. An invitation changes external relationship state and needs separate sender authority, recipient eligibility, provider approval, final review, budget, and outcome tracking.

How should the app retry a timed-out invitation command?+

Retry the status read using the same command reference, not the provider action. If the attempt may have crossed the provider boundary, keep it indeterminate until an approved reconciliation path proves the outcome.

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 ↗

Integrate invitation proposals into an application responsibly

Expose a proposal before any action

Bind the application's user to the acting account

Recheck relation and suppression state

Return a durable state instead of instant success

Translate acceptance only from observed evidence

Prove control across app, connector, and provider

Before you build.

Related guides

Evaluate company search for an authorized LinkedIn product

Replace the company-scraper idea with a lawful CRM intake design

Design a governed lead-intake workflow without automated extraction

Does this match the workflow your users need?