Evisort (Workday Contract Intelligence)

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

Evisort developer portal

Workflow API - intake forms, workflows, tickets

Documents API - metadata, fields and provisions

Admin API

Workday Contract Intelligence, powered by Evisort AI

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 - 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.

Ticket

Create a ticket against a published workflow - the primary publish target, and how an external system raises a contract request

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.

Ticket → reference field

Carrier for the Intent ID

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.

Ticket → counterparty

Counterparty capture at intake

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.

Document fields

Write structured metadata onto the resulting contract document

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.

Ticket document

Attach the decision record to the request

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

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

Evisort (Workday Contract Intelligence)

Integration path

Vendor documentation

Evisort developer portal

Workflow API - intake forms, workflows, tickets

Documents API - metadata, fields and provisions

Admin API

Workday Contract Intelligence, powered by Evisort AI

API posture

Publish target and field mapping

Next steps

How composerID connects

Publishing

All destinations

​Integration path

​Vendor documentation

Evisort developer portal

Workflow API - intake forms, workflows, tickets

Documents API - metadata, fields and provisions

Admin API

Workday Contract Intelligence, powered by Evisort AI

​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