ContractPodAi (Leah) (platform)
ContractPodAi is a contract lifecycle management platform, hosted on Microsoft Azure, whose AI layer is sold as Leah; contracts live as records of a tenant-configured contract type with their own metadata fields, fed by a request (intake) step and pushed to e-signature through DocuSign or Adobe Sign connectors. The vendor describes REST APIs and packaged connectors (Salesforce, SAP Ariba, Coupa, SharePoint, Microsoft 365) but publishes no self-service endpoint reference: the API documentation is provided to customers at onboarding. composerID publishes the services decision as a contract request that becomes a Contract record of the agreed type (SOW, services agreement or managed-service agreement), and the Intent ID lands in a custom metadata field on that Contract record configured for the purpose.
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 | Not publicly documented. Expect tenant-issued credentials (an OAuth 2.0 client or an API key bound to an integration user) supplied by the customer's ContractPodAi administrator at onboarding; the platform's SSO is Azure AD / SAML based, which is separate from API access. Indicative until confirmed at onboarding. |
|---|---|
| API style | REST, JSON (vendor statement; no public reference to confirm resource names, pagination or error shape) |
| Base URL | Per-customer tenant host, provisioned by ContractPodAi. No public base URL or path pattern is published. |
| Objects | Contract (typed by tenant-configured contract type, with metadata fields per type), Contract Request (intake), Counterparty / Third Party, Template and Clause library, Approval workflow, Obligation, Document (repository), e-signature envelope via DocuSign or Adobe Sign connector |
| Events / webhooks | No public webhook or event reference is known. Integrations with e-signature and ERP systems are connector based; assume status is read back by polling the Contract record until the tenant's API documentation shows otherwise. |
| Rate limits | Not published. Treat as tenant-negotiated; confirm limits and any burst allowance with the vendor at onboarding. |
No developer portal evident. We could not find a public self-service developer portal or endpoint reference for this platform; the API posture above is drawn from the vendor's own integration material and is confirmed at onboarding.
“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.
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 |
|---|---|---|---|---|
| Contract Request Open the intake for the services decision |
request_title (role_title / service summary), service_category, counterparty (supplier), start_date, end_date, budget, requester, business_unit | Contract Request (intake / request form), via the tenant REST API or the customer's connector | Required | Field names are tenant-configured per request form; the canonical set above is what composerID maps at onboarding. Indicative until confirmed. |
| Contract record The publish target: the services agreement itself |
contract_type (SOW, services agreement, managed-service agreement), sow.summary, deliverables[], dates, value, counterparty | Contract (tenant-configured contract type with its metadata fields) | Required | The Contract record is where the decision executes; templates and clause library are the tenant's. Indicative until confirmed at onboarding. |
| Intent ID correlation Carry the Intent ID |
intent_id -> custom metadata field on the Contract record (configured for the purpose, e.g. composerID), intent_version alongside | Custom metadata field on the Contract record | Required | ContractPodAi has no stock external-reference field that is publicly documented, so the carrier is a tenant-defined metadata field added to the relevant contract types at onboarding; once defined it is readable through the API and searchable in the repository. Deep link (illustrative): the UI route for a metadata search is not confirmed. |
| Contract status read-back Close the loop |
status, signed_date, effective_date, expiry_date | Contract record read (polled) | Read scope only | No public webhook reference; composerID polls the record it stamped and records the linkage on its side. |
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.
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
What gets produced
Portable artefacts
Important: where this platform is tenant-definedExpand
Everything about this destination is confirmed with the customer's ContractPodAi tenant, not from public docs: the API reference, credentials, the request form and contract types, and the metadata field that will carry the Intent ID all come from the tenant administrator at onboarding. The carrier field must be added to every contract type composerID publishes into (SOW, services agreement, managed-service agreement); a field defined on one type is not visible on the others. Rate limits, pagination and any event mechanism are indicative until the tenant's documentation is in hand.
Use this page alongside the API + Schemas docs to implement: destination connection, preflight validation, publish, webhook back-sync and reconciliation.