Keep job publishing as an explicit, auditable provider action

The target LinkedIn catalog includes job management, but no create, update, close, validation, or provider-account behavior is implemented. This route defines the boundaries a future authorized integration would need.

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

Talk to us ↗Read technical guides →

Capability boundary

Job management is a decision-gated target

The broad job.manage catalog entry does not prove a callable endpoint or any particular posting entitlement. Provider/product authorization and qualified legal review remain mandatory before implementation or sale.

Catalog status and access: LinkedIn account products — decision gated, non official session
Authentication: A future job action must be tied to the authorized user account and the exact company or recruiter context that the provider permits; DewEngine has not validated those entitlements.
Resources: jobs, companies
Target actions: job.manage, company.get
Target events: account.status
Limitations and failures: No job operation is implemented; Posting eligibility, fields, review, billing, and lifecycle behavior are unverified; No job-specific event is declared
Release gates: LinkedIn account products — Qualified legal review and provider/product authorization are required before implementation or sale

Ownership

Prove the company and account context before writing

A job record should name the connected account, provider company identifier, acting user, and customer workspace. Display names are not sufficient authorization to publish or modify a company's listing.

Lifecycle

Model draft, publish, update, and close separately

Job management is not one generic mutation. A future adapter should expose only provider-supported transitions, retain the native job ID and state, and reject updates that do not match the current provider record.

Validation

Return field and entitlement failures before claiming publication

Location, description, company, employment details, and account entitlements may each affect acceptance. Normalized validation can help the product, but raw provider reasons need to remain available for correction.

Command safety

Use durable intent for state-changing job actions

Create and close operations should carry a stable command key and an audit trail of the requested content, actor, and provider result. An uncertain response must be reconciled before repeating an action that could create a duplicate listing.

Release evidence

Test the exact authorized account types

Before this route can describe usable behavior, DewEngine needs approved access, documented entitlements, real-account tests for every promised transition, error fixtures, and a decision on retention and deletion of job content.

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 publish a LinkedIn job now?+

No. Job management is a catalog target under the same decision gate as the LinkedIn connector.

Does job.manage guarantee every account can post?+

No. It is a target capability label, not proof of provider entitlement or a released method.

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 ↗