01
Documentation status
This route is educational, not API reference
DewEngine's capability catalog records a possible LinkedIn account product with target resources, methods, events, non-official session access, and a decision-gated release state. It has no implementation or conformance evidence. The words profile.get, message.send, or search.perform therefore describe planning vocabulary only. They are not URLs, SDK methods, or promises that a connected account can be created.
- Read the status beside every capability
- Do not turn target names into sample requests
02
Target model
Understand what the catalog does and does not say
The target resources are chats, messages, profiles, companies, relations, invitations, posts, search, and jobs. Target actions include messaging, profile and company reads, relation listing, invitations, search, post creation, and job management. Target events cover message observations, relation acceptance, and account status. The catalog does not define fields, URLs, scopes, product entitlements, or current provider behavior.
- Treat omitted operations as unsupported, not implied
- Keep product-specific extensions outside the common vocabulary
03
Release state
Decision-gated is stricter than planned
Planned work has a selected product direction but still lacks release proof. Decision-gated LinkedIn cannot proceed to implementation or sale until qualified legal review and provider or product authorization approve the exact path. Engineering controls such as pacing, audit, and kill switches would follow; they cannot substitute for the decision. Public documentation must preserve this distinction visibly.
- Fail closed in capability discovery
- Keep LinkedIn out of generated API references
04
Future contract
Require account scope and truthful outcomes
If approval ever arrives, customer resources would use opaque IDs scoped to workspace and connected account, optional fields with provenance, durable cursors, and explicit freshness. Provider-visible actions would require idempotency, approval, budgets, and acknowledged, failed, throttled, or indeterminate states. Events would need recorded fixtures, deduplication, and signed customer webhook delivery before documentation could advertise them.
- Never call provider acknowledgement recipient delivery
- Keep unknown action outcomes from automatic retry
05
Examples policy
Make every example executable only when the method is released
A code sample is a strong availability claim. Generated examples should come from the same manifest as OpenAPI and SDKs and run in verification. Gated guides may use conceptual schemas or state descriptions, but must avoid tokens, production URLs, curl commands, or client calls that appear functional. Sandbox examples need unmistakable labels and cannot be presented as provider conformance.
- Fail documentation checks when examples exceed the manifest
- Remove stale samples after a capability falls back
06
Evidence chain
Trace every released sentence to current proof
A future method page would link to provider authorization, eligible-product contract, schema and fixture tests, consented real-account smoke, failure and restriction handling, privacy lifecycle, tenant isolation, and dated operational ownership. Evidence expires after material provider or schema changes. Until that chain exists, DewEngine's LinkedIn documentation remains an honest requirements library and not an integration manual.
- Automate claim diffs against capabilities.json
- Review rendered HTML for visible non-availability boundaries