> ## 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. # Sirion > Sirion (Signature & Contract Management): the API posture, publish target and field mapping composerID publishes a decision reference through. This page records how composerID publishes into Sirion: 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. Sirion is an enterprise AI-native CLM covering authoring, negotiation, a central repository and post-signature obligation, SLA and supplier-performance management. Its B2B API is designed so that what can be done in the web application can be done through the API, so composerID publishes by creating a contract draft request and, where configured, triggering the e-signature flow. Sirion turns a decision into a governed, auditable agreement and then holds the obligations that follow from it; the decision itself is made upstream. Category: Signature & Contract Management. Coverage status: Specification mapped. Vendor documentation: gated (customer or SKU documentation). ## Integration path How composerID connects to this destination, at a glance. | Step | Detail | | -------------------- | ----------------------------------------------------------------------------------------------------------------- | | Authentication | OAuth 2.0 client credentials. | | composerID publishes | Contract draft request: Contract draft request with its template-driven static and custom fields | | Intent ID lands on | `contract_draft` `customFields.intentId`, written into the destination record | | Back-sync | Webhooks: the destination pushes events; composerID verifies each delivery and lands it on the intent's timeline. | ## Vendor documentation ## API posture | Aspect | Detail | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Authentication | OAuth 2.0 client credentials. A Sirion administrator generates client credentials for the B2B APIs and shares the client ID and secret with the integrator; token permissions and scopes are configured in the platform's OAuth client setup. Vendor guidance is a least-privilege integration principal with TLS 1.2 or better, IP allow-listing and regular credential rotation. | | Style | REST/JSON. Pagination conventions are not published. A vendor-published Workato connector and webhook triggers exist alongside the raw API, and in some estates integration is expected to route through that connector rather than direct REST calls. | | Base URL | Per-customer tenant hostname, supplied by the customer's Sirion administrator - there is no published subdomain or path pattern, and the SAP Ariba integration guide likewise takes the tenant hostname as a configuration parameter | | Webhooks | Native webhook events are documented at feature level: real-time triggers on contract changes, approvals and milestone events, plus job-status updates for bulk operations. Webhook rules can filter on static and custom select fields, so a tenant can scope events to composerID-originated records. No public event catalogue or payload schema exists, so treat the callback as a signal and re-read the contract before updating the audit spine. | | Events posture | Webhooks | | Rate limits | No numeric limits published. Release notes confirm limits exist and are token-type dependent (limits for external-type tokens were raised to support heavier integration workloads), but no values are published - agree throughput with the customer's Sirion team. | | Objects | Contracts, contract draft requests, templates (template list and metadata, including an external ID on templates), custom fields, e-signature requests, obligations and SLA/performance records, suppliers, users and role groups, plus bulk import jobs. | ## 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, counterparty, start\_date, end\_date, value, owner | | Target | Contract draft request with its template-driven static and custom fields | | Requirement | Tenant | | Notes | Mandatory fields follow the selected template and tenant configuration. Administrators control whether extraction fields create custom fields on contracts or on draft requests, so the same logical field may exist on one object and not the other. | | Mapping | Detail | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Canonical to destination | title, counterparty, start\_date, end\_date, value | | Target | Contract record - core fields plus tenant-defined custom fields | | Requirement | Tenant | | Notes | Publishing straight to the contract skips the draft and approval workflow, which suits importing an already-executed agreement but not one Sirion is meant to author. Confirm which path is enabled before mapping. | | Mapping | Detail | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Canonical to destination | intent\_id | | Target | A dedicated custom field on the contract or draft request | | Requirement | Tenant required | | Notes | Sirion's own integration guidance recommends external IDs as correlation keys so replays and retries upsert rather than creating new records. Templates expose an external ID, but whether the contract object does is unconfirmed, so provision an explicit custom field rather than relying on it. | | Mapping | Detail | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Canonical to destination | counterparty, owner | | Target | E-signature request raised through the B2B API against the drafted contract | | Requirement | Optional | | Notes | The underlying signature provider and routing are tenant-configured, so trigger the Sirion-side action rather than integrating the signature vendor directly. | | Mapping | Detail | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------- | | Canonical to destination | defence\_file\_ref | | Target | Webhook rule filtered on contract status, approval or milestone changes | | Requirement | Recommended | | Notes | Because rules filter on custom select fields, events can be scoped to composerID-originated records rather than the whole estate. | Almost everything a publisher touches here is tenant configuration: the tenant hostname, the OAuth client and its token scopes, the contract templates and their static and custom field sets, and the webhook rules and filters. The custom field carrying the Intent ID must be created by the customer's administrator and its system name confirmed before publishing is enabled. Rate limits are token-type dependent and unpublished, so throughput is agreed rather than assumed. Confirm too whether the customer is licensed for B2B API access and whether integration is expected to route through the vendor's Workato connector instead of direct REST calls. ## 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.