> ## 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.
# ContractPodAi (Leah)
> ContractPodAi (Leah): the API posture, publish target and field mapping composerID publishes a decision reference through.
This page records how composerID publishes into ContractPodAi (Leah): 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.
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.
Category: Signature & Contract Management. Coverage status: Specification mapped. Vendor documentation: gated (customer or SKU documentation). No developer portal is evident.
## Integration path
How composerID connects to this destination, at a glance.
| Step | Detail |
| -------------------- | --------------------------------------------------------------------------------------------------------------- |
| Authentication | Not publicly documented. |
| composerID publishes | Contract Request: Contract Request (intake / request form), via the tenant REST API or the customer's connector |
| Intent ID lands on | `Contract` `metadata.composerID`, 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
## API posture
| Aspect | Detail |
| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 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. |
| 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. |
| 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. |
| Events posture | Polling |
| Rate limits | Not published. Treat as tenant-negotiated; confirm limits and any burst allowance with the vendor at onboarding. |
| 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 |
## 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 | request\_title (role\_title / service summary), service\_category, counterparty (supplier), start\_date, end\_date, budget, requester, business\_unit |
| Target | Contract Request (intake / request form), via the tenant REST API or the customer's connector |
| Requirement | Required |
| Notes | Field names are tenant-configured per request form; the canonical set above is what composerID maps at onboarding. Indicative until confirmed. |
| Mapping | Detail |
| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------- |
| Canonical to destination | contract\_type (SOW, services agreement, managed-service agreement), sow\.summary, deliverables\[], dates, value, counterparty |
| Target | Contract (tenant-configured contract type with its metadata fields) |
| Requirement | Required |
| Notes | The Contract record is where the decision executes; templates and clause library are the tenant's. Indicative until confirmed at onboarding. |
| Mapping | Detail |
| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Canonical to destination | intent\_id -> custom metadata field on the Contract record (configured for the purpose, e.g. composerID), intent\_version alongside |
| Target | Custom metadata field on the Contract record |
| Requirement | Required |
| Notes | 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. |
| Mapping | Detail |
| ------------------------ | -------------------------------------------------------------------------------------------------------- |
| Canonical to destination | status, signed\_date, effective\_date, expiry\_date |
| Target | Contract record read (polled) |
| Requirement | Read scope only |
| Notes | No public webhook reference; composerID polls the record it stamped and records the linkage on its side. |
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.
## 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.