Avature

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

Avature (vendor site)

Avature ATS (product overview)

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.

Job

Open the approved demand

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

Intent ID correlation

Carry the Intent ID

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.

Contingent worker request

Contingent channel, module-dependent

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

Application status read-back

Close the loop

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

How composerID connects

The five ways composerID reaches a destination, and the minimum a destination must offer.

Publishing

Plan, preflight and publish: how a decision becomes a valid record in a destination.

All destinations

Every destination composerID documents, with its category and coverage status.

⌘I

Get started

Concepts

Guides

Destinations

Upstream connectors

API reference

Endpoints

Manuscript API (Triage)

Manuscript endpoints

Resources

Integration path

Vendor documentation

Avature (vendor site)

Avature ATS (product overview)

API posture

Publish target and field mapping

Next steps

How composerID connects

Publishing

All destinations

​Integration path

​Vendor documentation

Avature (vendor site)

Avature ATS (product overview)

​API posture

​Publish target and field mapping

​Next steps

How composerID connects

Publishing

All destinations

Integration path

Vendor documentation

API posture

Publish target and field mapping

Next steps