> ## 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. # Agiloft > Agiloft (Signature & Contract Management): the API posture, publish target and field mapping composerID publishes a decision reference through. 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 ## 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. | 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. | | 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. | | 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. | | 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. | | 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 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.