Eightfold (platform)

Eightfold is an AI-native Talent Intelligence Platform: a skills graph over positions, candidate and employee profiles, applications and internal mobility, sold as Talent Acquisition (including its own applicant tracking) and Talent Management. Its REST APIs expose positions, profiles, applications and employees behind OAuth 2.0 client credentials that Eightfold provisions per tenant. composerID publishes the approved permanent-hire decision as a Position (directly where Eightfold is the requisition system of record, otherwise via the ATS beneath it) and lands the Intent ID in a tenant-defined position custom field that is readable back through the Positions API.

Publish path
Direct API
composerID adapter → Eightfold API
Events back
Push + poll
events where enabled; poll fallback
API access
Confirm licence
gated docs; API access may be a separate SKU
Contract tier
Tier A
full loop: publish + events back
composerID carrier
Stamped
position custom_fields.intent_id: written into the record and read back; indicative until confirmed at onboarding
Tenant configuration (mandatory fields, approval chains, picklists) is a separate gate from vendor capability: it is discovered at preflight before first publish and may need destination admin changes. How composerID connects →
Reference
API at a glance

The public API facts composerID's adapter relies on. Tenant-specific details (custom fields, picklists, approval chains) are confirmed during connection and folded into the MappingProfile.

AuthenticationOAuth 2.0 client credentials: Eightfold provisions a client_id and client_secret per customer tenant (or per partner app) and issues short-lived bearer tokens; scopes are granted per API family (positions, profiles, applications, employees) at provisioning. Token endpoint host and token lifetime are indicative until confirmed at onboarding.
API styleREST, JSON; versioned resource paths (v2 family) with cursor or offset pagination on list reads
Base URLhttps://api.eightfold.ai (region-specific API hosts exist for EU and other data residencies; the exact host is confirmed per tenant at onboarding)
Objectspositions (requisitions and their postings), profiles (candidates and employees, skills-inferred), applications (candidate to position, with stage and status), employees, job postings on the careers site, talent network and campaigns, tenant-defined custom fields on positions and profiles
Events / webhooksEightfold references outbound event notifications for application and position changes in the developer portal, but the event catalogue, delivery signing and retry semantics are not confirmed here. Plan poll-first on Positions and Applications reads with updated-since filtering, and treat webhooks as a supplement once the tenant's event subscription is proven.
Rate limitsNot stated in any public reference we can confirm; assume conservative per-tenant throttling, honour 429 with exponential backoff, and keep publishes idempotent on the Intent ID. Indicative until confirmed at onboarding.
Readiness
Docs confidence: Customer

“Docs confidence” describes how deterministic our mapping templates can be before we connect to a tenant. Even with public docs, implementations vary, especially around custom fields, approval flows and object extensions.

Deterministic mapping

Common Workforce Model fields map to known API fields. Best for standard objects (requisitions, assignments, timesheets, POs).

Tenant discovery

composerID can scan tenant configuration (custom fields, picklists, required fields) where the platform permits it, then generate a tenant‑specific MappingProfile.

Enrichment loop

If the target platform requires a field the Intent record doesn't yet have, composerID emits an enrichment_request back to the intake layer.

Mapping
Minimum viable mapping for Eightfold

An opinionated baseline. The platform adapter enforces additional requirements via preflight. “Tenant required” fields are discovered during connection and added to the MappingProfile.

Object Canonical fields Platform target Required status Notes
Position
Open the approved demand
role_title, department or business unit, location, hiring_manager, headcount, employment_type, required skills Positions API (create or update Position) Required Applies where Eightfold Talent Acquisition is the requisition system of record. Where an ATS or HRIS sits beneath Eightfold, that integration owns position creation and composerID publishes into the ATS instead; Eightfold then carries the ATS requisition reference on the synced Position. Field names indicative until confirmed at onboarding.
Intent ID correlation
Carry the Intent ID
intent_id -> custom_fields.intent_id (Position); fallback: the Position's client-supplied external reference when Eightfold is the requisition system of record Position custom field (tenant-defined) via Positions API Required The custom field is provisioned on the tenant and must be exposed as searchable so the Position can be found by Intent ID on read-back. Where the ATS reference slot is free (no upstream ATS), it is the preferred stock carrier. Deep link https://{tenant_host}/positions?q={external_id} (illustrative).
Application and hire read-back
Close the loop
application status and stage, hired candidate profile id, position status (open, filled, closed) Applications API and Positions API reads; event notifications where the tenant enables them Read scope only Read-back correlates on the Position's Intent ID custom field. Poll on updated-since until the tenant's event subscription is proven; hire and close events update the intent timeline.
Idempotency & drift: publish + reconcileExpand

Publish operations are idempotent using a deterministic key {intent_id}-{intent_version}-{target_system}. Because humans can change records inside the platform, composerID supports reconciliation: it compares the platform record snapshot to the canonical intent and flags drift.

Tenant specifics
Custom fields & unique mapping

Real deployments rely on program-specific custom fields (for compliance, approvals, GL coding, rate rules or supplier constraints). composerID is designed to generate tenant‑specific mappings rather than forcing you to redesign your intake.

How scanning works

High-level flow

connect_destination() → read required fields + picklists (where permitted) → detect custom fields / extensions → build MappingProfile + validation rules → preflight intent against tenant requirements

What gets produced

Portable artefacts

MappingProfile (tenant-scoped) Capabilities matrix Required-field rules Picklist dictionaries Enrichment prompts Audit spine links (defence_file_ref)
Important: where this platform is tenant-definedExpand

API access is provisioned, not self-served: Eightfold issues OAuth client credentials and API-family scopes per customer tenant (or per partner app), and tenants are hosted regionally, so the API host is tenant-specific. Most deployments run Eightfold on top of an ATS or HRIS of record (Workday, SuccessFactors, Greenhouse and others); in that topology Eightfold ingests positions from the ATS and composerID should publish into the ATS, letting Eightfold carry the ATS requisition reference on the synced Position. Direct Position creation applies only where Eightfold Talent Tracking is the requisition system of record. Position custom fields are tenant-defined and must be created and made searchable before the first publish. Webhook availability, rate limits and exact field names are indicative until confirmed at onboarding.

Next
Implement the adapter

Use this page alongside the API + Schemas docs to implement: destination connection, preflight validation, publish, webhook back-sync and reconciliation.