> ## 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. # Avature > Avature (ATS): the API posture, publish target and field mapping composerID publishes a decision reference through. This page records how composerID publishes into Avature: 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. Avature is an enterprise talent platform (CRM, ATS, onboarding, internal mobility and a separately licensed Contingent Workforce Management module) that runs on a customer instance at \{tenant}.avature.net. Its REST web services are enabled and shaped per instance by the customer's administrators, so the records, fields and services a tenant exposes are configuration rather than a fixed public contract, and the reference documentation sits behind the customer login. composerID publishes the approved demand as a Job record through the instance's REST web service and lands the Intent ID in a tenant-defined text field on that Job, readable back by query on the same service. Category: ATS. Coverage status: Specification mapped. Vendor documentation: gated (customer or SKU documentation). No developer portal is evident. ## Integration path How composerID connects to this destination, at a glance. | Step | Detail | | -------------------- | -------------------------------------------------------------------------------------------------------------- | | Authentication | Instance-issued API key for a named integration user, sent as a request header on every call. | | composerID publishes | Job: Job record (create) on the instance's REST web service | | Intent ID lands on | `job` `customFields.intentId`, written into the destination record | | Back-sync | Polling: the destination publishes no events composerID can subscribe to, so state is read back on a schedule. | ## Vendor documentation ## API posture | Aspect | Detail | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Authentication | Instance-issued API key for a named integration user, sent as a request header on every call; the key is created and scoped by the customer's Avature administrators when they enable the web service, and the header name and key lifecycle are taken from the instance's own documentation at onboarding. No public self-service OAuth client registration is evident. | | Style | REST over HTTPS with JSON bodies, exposed as per-instance web services that administrators enable record type by record type (Jobs, People, Applications, Forms, Workflows). Each instance publishes its own reference for the services it has switched on; there is no single public endpoint catalogue. | | Base URL | https\://\{tenant}.avature.net (REST web services sit under an instance-specific path; the prefix and service names are read from the tenant's own reference at onboarding, not assumed) | | Webhooks | No public webhook product or event catalogue is evident. Reads are by query on the record's fields through the same web service. Where a tenant's workflow configuration can call an external URL when a Job or Application changes step, that is instance configuration and indicative until seen; treat Avature as poll-first. | | Events posture | Polling | | Rate limits | Not published. Any throttling is agreed per instance with Avature; confirm limits, page sizes and batch behaviour at onboarding. | | Objects | Jobs (requisition-style records with instance-defined fields and approval workflows), People (candidates and contacts), Applications (a Person's progress on a Job through workflow steps), Forms, Workflows and Lists. The Contingent Workforce Management module adds its own worker request and engagement records where licensed. | ## 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, hiring\_manager, location, department, headcount, employment\_type, start\_date | | Target | Job record (create) on the instance's REST web service | | Requirement | Required | | Notes | Field names are instance-defined; the tenant maps canonical intent fields onto its configured Job fields at onboarding | | Mapping | Detail | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Canonical to destination | intent\_id -> Job.customFields.intentId (tenant-defined text field on the Job) | | Target | Job record field, written on create and read back by query on the same web service | | Requirement | Required | | Notes | Avature has no stock client-supplied external reference we can cite, so the tenant adds one text field for the Intent ID and exposes it on the Job web service; composerID also records the linkage on its side. Deep link https\://\{tenant\_host}/jobs/\{external\_id} is illustrative until the admin UI route is confirmed. | | Mapping | Detail | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Canonical to destination | role\_title, start\_date, end\_date, rate\_band, cost\_center, worker\_type | | Target | Contingent Workforce Management request record (create), where the module and its web service are enabled | | Requirement | Tenant required | | Notes | Only where the Contingent Workforce Management module is licensed; record and field names are confirmed per instance and the Intent ID rides a tenant-defined field on that record in the same way as the Job | | Mapping | Detail | | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------- | | Canonical to destination | application.step, hired flag, start\_date, keyed by the Job's Intent ID field | | Target | Application and Job records (read by query) on the instance's REST web service | | Requirement | Read scope only | | Notes | Query Jobs by the Intent ID field and Applications by Job to tie hires back to the decision reference; no signed event feed is assumed | Every Avature instance is bespoke: the web services, record types and fields available to composerID exist only once the customer's administrators enable them, so onboarding starts with an instance inventory (which services are on, which Job fields exist, whether a text field is free to hold the Intent ID and is exposed on the Job web service) rather than a fixed contract. Only the tenant can tell us the header name and lifecycle of the integration user's API key, the service path prefix, page sizes and any throttling agreed with Avature, whether any workflow step calls out to an external URL, and whether the Contingent Workforce Management module is licensed at all. Every endpoint shape above is indicative until confirmed against the instance's own reference. ## 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.