Planned capability

ATS product engineering

Embed candidate communication without owning provider plumbing

Plan a publisher integration that lets an ATS connect recruiter-owned accounts, attach provider activity to candidate records, and coordinate permitted communication from its existing interface. DewEngine would manage connector lifecycle; the ATS retains candidate identity, hiring permissions, job context, workflow, retention, and decision authority.

Illustrative product surface. The workflows below are planned, not a live connector.

Talk to us ↗Read technical guides →

Planned boundary

The ATS publisher contract has not shipped

This embedded ATS capability is planned and not callable. There is no released publisher application model, recruiter connection flow, candidate resource mapping, inbox component, professional messaging method, mailbox synchronization, or interview API.

Current evidence: Development code provides workspace API keys, connected-account records, redirect allowlists, Google Calendar auth intents, durable commands, events, and webhooks. It lacks customer users and roles, ATS tenant delegation, candidate references, released mail or messaging providers, and complete scheduling behavior.
Target contract: Map each ATS customer and recruiter to a DewEngine workspace and acting account without transferring provider credentials into the ATS database; Carry tenant-scoped candidate and requisition references through commands and events while provider identities remain source-specific; Expose account capability, reconnect state, and provider outcome so the ATS can render only valid actions and recoveries
Known limits: DewEngine will not become the candidate system of record, resolve duplicate applicants conclusively, determine hiring stage, or authorize recruiter access; Professional networks, mailboxes, messaging accounts, and calendars impose different scopes, eligibility, retention, notification, and automation restrictions
Release gates: Implement publisher application identity, delegated recruiter roles, scoped keys, account ownership, and tenant-safe external references; Release the selected provider verticals with backfill, replies, reconnect, retirement, provider ambiguity, and event conformance; Validate candidate access, correction, deletion, shared inboxes, interview changes, and audit with ATS publisher fixtures

Publisher boundary

Let the ATS keep its domain authority

Candidates, applications, requisitions, interview plans, recruiter teams, and stage transitions belong in the ATS. DewEngine needs only opaque references required to return communication state to the right record. This minimizes copied hiring data and prevents connector workers from becoming a hidden workflow engine that can advance or reject applicants.

Store only the external references required for correlation
Never infer candidate stage from message activity

Implementation onboarding

Connect the recruiter inside the ATS tenant

The ATS server authenticates its user, creates a short-lived provider intent for that tenant, and embeds or redirects to the hosted flow. On completion, only an opaque account ID and bounded status return. The ATS associates it with the recruiter under its role system; another customer or colleague cannot claim it by knowing the identifier.

Allowlist exact callback origins per publisher environment
Show account subject and requested product before final confirmation

Activity ingestion

Attach provider events through stable correlation

Incoming observations resolve first to workspace, connected account, native thread, and canonical resource. The ATS can then use its reviewed association to place activity on a candidate timeline. A duplicate webhook must not duplicate a note, and a corrected association should move presentation without rewriting the original provider lineage.

Deduplicate by DewEngine event ID and resource version
Keep association history when an ATS user corrects a match

Write controls

Authorize recruiter actions at two layers

The ATS checks role, requisition access, candidate preference, communication purpose, and content approval. DewEngine then checks the connected account, released provider method, conversation rules, pacing, and health. A success at either layer cannot override a refusal at the other, and dispatch-time revalidation catches permissions changed after a draft was prepared.

Record both ATS approval and connector eligibility decisions
Expire queued candidate contact when its requisition context closes

Release acceptance

Prove multi-tenant recovery before embedding

Publisher tests must cover recruiter departure, account reassignment, two ATS customers sharing an email domain, duplicate candidates, withdrawn consent, inaccessible threads, calendar reschedule, expired callbacks, and provider outages. Support tooling needs a correlation path that diagnoses connector state without granting DewEngine access to unrelated candidate fields.

Run tenant-confusion attacks through callbacks and webhooks
Document which party answers each recruiter and candidate support request

Illustrative contract

Preview the intended integration boundary.

This shape documents the intended account and resource boundary. It is not callable, and it does not generate provider traffic.

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

Illustrative shapePlanned · not callable

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

No live connector · no provider request

Questions

Before you build.

Would an ATS need to store recruiter provider credentials?+

The target design avoids that. The ATS would retain a DewEngine account identifier and its own recruiter association, while encrypted provider authorization remains inside the qualified connector boundary.

Can candidate stage changes be triggered from any incoming message?+

That is an ATS product decision, not a connector default. The ATS must verify the candidate association, event meaning, workflow rules, and user permissions before changing an application record.

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 ↗