> ## Documentation Index
> Fetch the complete documentation index at: https://www.composer.id/llms.txt
> Use this file to discover all available pages before exploring further.
# Eightfold
> Eightfold (ATS): the API posture, publish target and field mapping composerID publishes a decision reference through.
This page records how composerID publishes into Eightfold: the vendor's API posture, the publish target and field mapping, and the documentation each claim rests on. It is for anyone evaluating the connection or building against it.
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.
Category: ATS. Coverage status: Specification mapped. Vendor documentation: gated (customer or SKU documentation).
## Integration path
How composerID connects to this destination, at a glance.
| Step | Detail |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Authentication | OAuth 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. |
| composerID publishes | Position: Positions API (create or update Position) |
| Intent ID lands on | `position` `custom_fields.intent_id`, written into the destination record |
| Back-sync | Webhooks and polling: some lifecycle events are pushed, the rest are read on a schedule. |
## Vendor documentation
## API posture
| Aspect | Detail |
| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Authentication | OAuth 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. |
| Style | REST, JSON; versioned resource paths (v2 family) with cursor or offset pagination on list reads |
| Base URL | [https://api.eightfold.ai](https://api.eightfold.ai) (region-specific API hosts exist for EU and other data residencies; the exact host is confirmed per tenant at onboarding) |
| Webhooks | Eightfold 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. |
| Events posture | Webhooks and polling |
| Rate limits | Not 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. |
| Objects | positions (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 |
## Publish target and field mapping
Each object below pairs the canonical intent fields with the destination's own fields and operations. The mapping is indicative until it is confirmed against a tenant at onboarding.
| Mapping | Detail |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Canonical to destination | role\_title, department or business unit, location, hiring\_manager, headcount, employment\_type, required skills |
| Target | Positions API (create or update Position) |
| Requirement | Required |
| Notes | 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. |
| Mapping | Detail |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Canonical to destination | intent\_id -> custom\_fields.intent\_id (Position); fallback: the Position's client-supplied external reference when Eightfold is the requisition system of record |
| Target | Position custom field (tenant-defined) via Positions API |
| Requirement | Required |
| Notes | 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). |
| Mapping | Detail |
| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Canonical to destination | application status and stage, hired candidate profile id, position status (open, filled, closed) |
| Target | Applications API and Positions API reads; event notifications where the tenant enables them |
| Requirement | Read scope only |
| Notes | 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. |
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 steps
The five ways composerID reaches a destination, and the minimum a destination must offer.
Plan, preflight and publish: how a decision becomes a valid record in a destination.
Every destination composerID documents, with its category and coverage status.