> ## 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. # Evisort (Workday Contract Intelligence) > Evisort (Workday Contract Intelligence): the API posture, publish target and field mapping composerID publishes a decision reference through. This page records how composerID publishes into Evisort (Workday Contract Intelligence): 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. Evisort is an AI-native contract intelligence and lifecycle platform, acquired by Workday and now marketed as Workday Contract Intelligence, powered by Evisort AI. composerID publishes into it by raising a ticket against a published workflow - the same intake path a human would use - so a decision already taken becomes a contract request that Evisort's workflow, review and extraction layers execute against. It is the paper and intelligence layer for that decision, not the system that makes it. Category: Signature & Contract Management. Coverage status: Specification mapped. Vendor documentation: public developer portal. ## Integration path How composerID connects to this destination, at a glance. | Step | Detail | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | Authentication | An API key minted by the user in the Evisort UI is exchanged for a short-lived JWT, which is then presented as a bearer token on subsequent calls. | | composerID publishes | Ticket: Ticket name / the corresponding intake-form field | | Intent ID lands on | `ticket` `intakeFields.intent_id`, 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 | An API key minted by the user in the Evisort UI is exchanged for a short-lived JWT, which is then presented as a bearer token on subsequent calls. No OAuth 2.0 authorization-code or client-credentials flow is publicly documented, so the integration identity is a named user's key - agree ownership and rotation before go-live. | | Style | REST/JSON versioned at /v1, split across separately documented surfaces rather than one monolith: Documents, Workflow, Admin and Audit Logs. Independently hosted rather than Salesforce-platform-based. Pagination conventions are not publicly documented. | | Base URL | [https://api.evisort.com/v1](https://api.evisort.com/v1) - a single host, with tenancy resolved by the API key rather than a per-customer subdomain | | Webhooks | No webhook or event-subscription API appears in the public developer documentation. The nearest event surface is the Audit Logs API, which exposes a read-only view of events within a workspace - a pull surface, not a push one. Plan on polling ticket and document state, or the audit log, for status back. | | Events posture | Polling | | Rate limits | None published. Limits appear to be enforced server-side, so handle 429 responses and agree expected throughput with the tenant rather than assuming headroom. | | Objects | Workflow API: intake forms and their field options, published workflows, tickets (create, get, update), ticket documents, ticket judgments, activities. Documents API: document upload (new document and new version), field update on a document, and metadata endpoints listing fields and provisions. Admin and Audit Logs APIs cover users and workspace audit events. | ## 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 | title | | Target | Ticket name / the corresponding intake-form field | | Requirement | Required | | Notes | The payload is shaped by the selected workflow's intake form, so composerID reads the intake form and its field options for the target workflow rather than posting a fixed body. | | Mapping | Detail | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Canonical to destination | intent\_id | | Target | Tenant-configured intake-form field on the workflow, mirrored onto the resulting document as a custom field | | Requirement | Tenant required | | Notes | No standard external-reference or idempotency-key field is documented on tickets or documents, so the field must exist on the published workflow's intake form before composerID can publish, and duplicate suppression is the publisher's responsibility. | | Mapping | Detail | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | Canonical to destination | counterparty | | Target | Counterparty / party intake-form field | | Requirement | Tenant | | Notes | Whether this is free text, a picklist or a lookup depends entirely on how the workflow was authored - read the intake form's field options before mapping. | | Mapping | Detail | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Canonical to destination | start\_date, end\_date, value, owner | | Target | Document metadata fields and provisions | | Requirement | Tenant | | Notes | Field names are case-sensitive on update, and the tenant's field set must be enumerated first. Supplied values also compete with Evisort's own AI extraction, so precedence between provided and extracted values is a tenant decision. | | Mapping | Detail | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------ | | Canonical to destination | defence\_file\_ref | | Target | Document attached to the ticket, or a version uploaded against the record | | Requirement | Recommended | | Notes | Stores the rationale with the contract so the extraction layer and any later auditor both see why the engagement was approved. | Nearly everything a publisher touches here is tenant-authored: which workflows are published, what fields their intake forms expose and in what shape, and which document metadata fields and provisions exist. composerID discovers the target workflow, reads its intake form and field options, and enumerates document fields per customer rather than mapping to a fixed schema. The Intent ID carrier field has to be added to the intake form by the customer's administrator before publishing can work. API keys are minted per user in the UI, so the integration identity and its rotation are a customer-side decision - and following the Workday acquisition, confirm whether the tenant is on standalone Evisort or Workday-provisioned Contract Intelligence, since that governs provisioning and identity. ## 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.