Conga CLM (platform)

Conga CLM is an enterprise contract-lifecycle platform of Apttus lineage, shipped in two materially different deployments: CLM for Salesforce (a managed package running inside the customer's own Salesforce org) and CLM on the Conga Advantage Platform (Conga-hosted REST APIs). composerID publishes into Conga by creating or amending an Agreement record once a decision has been taken, carrying the Intent ID onto that record so the paper reconciles back to the decision. Conga records and progresses the agreement; it is not the system that decided the engagement should happen.

API at a glance Minimum viable mapping Custom fields & tenant mapping

Publish path

Direct API

composerID adapter → Conga CLM API

Events back

Push + poll

events where enabled; poll fallback

API access

Open docs

public developer portal

Contract tier

Tier A

full loop: publish + events back

Tenant configuration (mandatory fields, approval chains, picklists) is a separate gate from vendor capability: it is discovered at preflight before first publish and may need destination admin changes. How composerID connects →

Reference

API at a glance

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	Deployment-dependent, and the two are not interchangeable. Advantage Platform: OAuth 2.0 client credentials - a Conga API Connection issues a client ID and secret, exchanged for a bearer token with roughly an hour's lifetime. CLM for Salesforce: authentication is Salesforce's own OAuth 2.0 against the customer org (the legacy SOAP surface authenticates via an Apttus login call first).
API style	Advantage Platform: REST/JSON with resource-oriented URLs and HTTP status codes for errors. CLM for Salesforce is Salesforce-platform-based, which changes both auth and object model - the surface is Salesforce REST/SOAP over managed-package objects plus Conga Apex REST services, so a publisher connects to the customer's Salesforce org rather than a Conga-hosted tenant. A SOAP Agreement Web Service covers activate, select-template and publish operations. Pagination conventions are not publicly documented.
Base URL	Advantage Platform: https://rls.congacloud.com/api/clm/v1/... · CLM for Salesforce: https://{myorg}.force.com/services/apexrest/Apttus/clm/{version}/{API} alongside the org's standard Salesforce REST endpoints
Objects	Advantage Platform CLM v1: contracts (create-offline, amend, activate, terminate), contract clauses, supporting documents, document generation and preview, reviews. CLM for Salesforce: the managed-package Agreement object and its related clause, template and document records, exposed via Salesforce REST/SOAP plus the Agreement Web Service.
Events / webhooks	No CLM-specific webhook or event-subscription API is publicly documented. Webhooks are documented for adjacent Conga products (Conga Sign event notifications, and the separate Novatus-lineage Conga Contracts) - do not assume they cover CLM. Salesforce-hosted deployments can use Salesforce-native Platform Events and Change Data Capture, but that is a Salesforce capability rather than a Conga-documented CLM one, so confirm the event path per deployment.
Rate limits	None published for CLM on either deployment. For CLM for Salesforce the binding constraint is the customer's own Salesforce org limits, including per-transaction governor limits and total org API calls per rolling 24 hours; no limits are documented for the Conga-hosted endpoints.

Developer access

The Conga CLM API details are for registered developers

Auth model, base URLs, event posture and rate limits, free with a developer account.

Get free access → Registered developers are recognised automatically.

Readiness

Docs confidence: Public

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

Mapping

Minimum viable mapping for Conga CLM

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
Agreement / contract record Advantage Platform: create against the CLM v1 contracts resource. Salesforce: insert the managed-package Agreement object, then use the Agreement Web Service to select a template and generate.	title	Contract / agreement name	Required	The publish target is the agreement record itself; document generation is a second step against the created record rather than part of creation.
Agreement → reference field Carrier for the Intent ID	intent_id	Tenant-defined custom field on the agreement record (on Salesforce, optionally flagged as an External ID)	Tenant required	No standard external-reference field is documented on either deployment. On Salesforce the External ID pattern gives genuine idempotent upsert-by-key - a Salesforce platform capability, not a Conga feature; on the Advantage Platform, treat create as non-idempotent and reconcile by search.
Agreement → counterparty Account or party association	counterparty	Account / party record referenced by the agreement	Required	Salesforce deployments resolve to a Salesforce Account; Advantage Platform deployments to the platform's account record. Either way the counterparty must pre-exist or be created first, so agree a look-up-or-create strategy per tenant.
Agreement → commercial terms Term and value fields on the agreement header	start_date, end_date, value	Contract term start and end dates, contract value	Tenant	Field API names differ between the managed package and the Advantage Platform contract model, and are commonly extended per customer - confirm against the tenant's schema rather than mapping generically.
Supporting document Attach the decision record alongside the paper	defence_file_ref	Supporting document on the contract record (Advantage Platform), or the publish-document operations on the Agreement Web Service (Salesforce)	Recommended	Keeps the rationale travelling with the agreement so an auditor reading the contract can reach the decision behind it.

Developer access

The field-level mapping is for registered developers

Object targets, canonical fields and the Intent ID carrier for Conga CLM, free with a developer account.

Get free access → Registered developers are recognised automatically.

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.

Tenant specifics

Custom fields & unique mapping

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

connect_destination() → read required fields + picklists (where permitted) → detect custom fields / extensions → build MappingProfile + validation rules → preflight intent against tenant requirements

What gets produced

Portable artefacts

MappingProfile (tenant-scoped) Capabilities matrix Required-field rules Picklist dictionaries Enrichment prompts Audit spine links (defence_file_ref)

Important: where this platform is tenant-definedExpand

The first question on any Conga engagement is which Conga CLM this is: the Salesforce managed package or CLM on the Conga Advantage Platform. They differ in authentication, base URL and object model, and a connector built for one does not work against the other. Conga's estate also contains several similarly named contract products (Conga Contracts and Conga Contracts for Salesforce are a different lineage again), so confirm the product, not just the vendor. Beyond that, the Intent ID carrier field, the agreement record type, the generation template and the approval path are all tenant-configured; on Salesforce deployments the customer's org API limits and managed-package version also constrain throughput.

Developer access

Tenant-mapping notes are for registered developers

Where Conga CLM deployments differ tenant to tenant, and what to check before first publish.

Get free access → Registered developers are recognised automatically.

Implement the adapter

Use this page alongside the API + Schemas docs to implement: destination connection, preflight validation, publish, webhook back-sync and reconciliation.

Back to Platforms How integrations work API reference