Avature (platform)
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.
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.
| 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. |
|---|---|
| API 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) |
| 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. |
| Events / 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. |
| Rate limits | Not published. Any throttling is agreed per instance with Avature; confirm limits, page sizes and batch behaviour at onboarding. |
No developer portal evident. We could not find a public self-service developer portal or endpoint reference for this platform; the API posture above is drawn from the vendor's own integration material and is confirmed at onboarding.
“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.
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 |
|---|---|---|---|---|
| Job Open the approved demand |
role_title, hiring_manager, location, department, headcount, employment_type, start_date | Job record (create) on the instance's REST web service | Required | 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 |
intent_id -> Job.customFields.intentId (tenant-defined text field on the Job) | Job record field, written on create and read back by query on the same web service | Required | 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 |
role_title, start_date, end_date, rate_band, cost_center, worker_type | Contingent Workforce Management request record (create), where the module and its web service are enabled | Tenant required | 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 |
application.step, hired flag, start_date, keyed by the Job's Intent ID field | Application and Job records (read by query) on the instance's REST web service | Read scope only | 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 |
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.
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
What gets produced
Portable artefacts
Important: where this platform is tenant-definedExpand
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.
Use this page alongside the API + Schemas docs to implement: destination connection, preflight validation, publish, webhook back-sync and reconciliation.