Agiloft

This page records how composerID publishes into Agiloft: 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. Agiloft is a no-code CLM built on a knowledgebase of user-definable tables, records, rules and workflows - the contract table is one instance of that model rather than a fixed schema. composerID publishes into Agiloft by creating a contract record in the customer’s knowledgebase and setting the fields their configuration requires, so an approved decision becomes a tracked record moving through the tenant’s own approval and signature workflow. Agiloft records, routes and enforces the agreement; the decision about what to buy and from whom is made upstream.

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	OAuth 2.0 is the documented modern path: an API application registered inside the knowledgebase defines the grant type, the user account whose permissions govern data access, and the client identifier, and a token exchange yields a bearer token.
composerID publishes	Contract record (create): Contract title field on the contract table
Intent ID lands on	`contract_record` `customFields.intentId`, written into the destination record
Back-sync	Webhooks and polling: some lifecycle events are pushed, the rest are read on a schedule.

Vendor documentation

REST Interface

Using OAuth2 to access the REST API

REST - Read

Webhooks

Agiloft Developer Guide (PDF)

API posture

Aspect	Detail
Authentication	OAuth 2.0 is the documented modern path: an API application registered inside the knowledgebase defines the grant type, the user account whose permissions govern data access, and the client identifier, and a token exchange yields a bearer token. ExtAuth remains as a legacy mechanism, and the classic interface accepts credentials as $login /$ password parameters or a session token from EWLogin.
Style	REST over HTTP in an operation-per-endpoint style (EWCreate, EWUpdate, EWSelect, EWDelete, EWLogin, EWLock, EWAttach) rather than resource-oriented REST, with a parallel SOAP web-services API offering equivalent operations. The classic interface is XML-oriented.
Base URL	Tenant-hosted: https://{instance}.agiloft.com/ewws/{operation} - every call carries the knowledgebase as $KB and the target table as$ table
Webhooks	Outbound webhooks are an administrator-configured feature registered under Setup → Integration → Webhook Setup; each fires on record created, record updated or both, and carries HTTP headers the administrator supplies. There is no fixed event catalogue and no documented payload-signing mechanism, so authenticate the callback with a header and treat event coverage as a per-knowledgebase decision. The Workato-based Integration Hub provides further event-driven paths.
Events posture	Webhooks and polling
Rate limits	None published. Agiloft documents no request quotas, throttling or concurrency caps; practical limits follow the customer’s hosting tier and knowledgebase configuration and should be confirmed with Agiloft per deployment.
Objects	Knowledgebase tables and their records addressed by logical table name - in a CLM knowledgebase principally the contract/agreement table, plus companies and parties, people and contacts, attachments and approval records. Workflow transitions and action buttons can also be triggered through the interface.

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.

Contract record (create)

EWCreate against the knowledgebase's contract table, addressed by its logical $table name

Mapping	Detail
Canonical to destination	title
Target	Contract title field on the contract table
Requirement	Required
Notes	The table’s logical name and the field’s internal name are both knowledgebase-specific and differ from the display labels administrators see in the UI.

Contract record → reference field

A custom text field added to the contract table for the publisher's reference

Mapping	Detail
Canonical to destination	intent_id
Target	Custom single-line text field (knowledgebase-defined; no standard external-ID field is documented)
Requirement	Tenant required
Notes	Because knowledgebases are user-definable by design, the Intent ID needs a purpose-added text field - ideally searchable via EWSelect so a re-publish looks up the existing record instead of creating a duplicate.

Contract record → counterparty

Usually a linked-field relationship to the companies table rather than free text

Mapping	Detail
Canonical to destination	counterparty
Target	Company / party linked field on the contract record
Requirement	Tenant
Notes	Linked fields resolve against an existing record in the related table, so publishing may need a look-up-or-create step against companies before the contract create call succeeds.

Contract record → term and value

Date and currency fields, or Key Term records, on the contract table

Mapping	Detail
Canonical to destination	start_date, end_date, value
Target	Contract start date, end date and value fields (knowledgebase-named)
Requirement	Tenant
Notes	Agiloft models key terms such as contract title and start date as their own records, so a knowledgebase may expect these as key-term rows as well as, or instead of, plain fields. Confirm which per tenant.

Webhook subscription

Setup → Integration → Webhook Setup, scoped to the contract table

Mapping	Detail
Canonical to destination	defence_file_ref
Target	Outbound POST on record created or updated, correlated on the reference field
Requirement	Recommended
Notes	The webhook is enabled by the customer’s administrator rather than by the API client, so event delivery is provisioned during onboarding rather than assumed.

Agiloft is configuration-first, so almost nothing about the contract schema is universal. Per customer, confirm: the knowledgebase name (

KB) and the contract table's logical name (

table); the internal field names, which differ from display labels; which fields the knowledgebase marks mandatory, since the API rejects a create that leaves any unsatisfied; whether counterparties are linked records or text; whether commercial terms live in plain fields or key-term records; and which custom text field carries the Intent ID. The user account registered against the OAuth application governs record-level permissions, so a publish can fail on visibility rules rather than on payload shape. Webhook registration is an administrator action inside the customer’s own knowledgebase.

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

REST Interface

Using OAuth2 to access the REST API

REST - Read

Webhooks

Agiloft Developer Guide (PDF)

API posture

Publish target and field mapping

Next steps

How composerID connects

Publishing

All destinations

​Integration path

​Vendor documentation

REST Interface

Using OAuth2 to access the REST API

REST - Read

Webhooks

Agiloft Developer Guide (PDF)

​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