> ## 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. # LinkSquares > LinkSquares (Signature & Contract Management): the API posture, publish target and field mapping composerID publishes a decision reference through. This page records how composerID publishes into LinkSquares: 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. LinkSquares splits contract lifecycle management across Finalize (pre-signature intake, drafting and workflow) and Analyze (a post-signature repository whose AI extracts metadata from executed documents). Which half composerID publishes into changes the payload materially: Finalize takes a request or draft for the legal team to pick up, Analyze takes an executed document plus the metadata the source system already knows. Either way LinkSquares is the paper and evidence layer for a decision taken upstream, and it carries the Intent ID so the agreement traces back to the intent that caused it. 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 | Static API key sent as an x-api-key request header over HTTPS. | | composerID publishes | Agreement (Finalize): Finalize agreement or request, plus its agreement detail fields | | Intent ID lands on | `agreement` `terms.intent_id`, 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 | Static API key sent as an x-api-key request header over HTTPS. Keys are generated by administrators and each is bound to one user and one company, so provision a service account rather than reusing a named user. No OAuth flow is documented. | | Style | REST/JSON with a published OpenAPI 3.0 specification, distributed as a downloadable file rather than a hosted spec. Analyze list endpoints use cursor-based pagination rather than page numbers. Document upload is a two-step flow: create the metadata record, then PUT the file to a returned pre-signed URL. | | Base URL | [https://api.linksquares.com](https://api.linksquares.com) - a single shared host with product-scoped, versioned paths (analyze and finalize are versioned independently); tenancy resolves from the API key rather than a subdomain | | Webhooks | No vendor-documented webhook or event-subscription surface. The Finalize API is described in terms of reading agreement status and version updates, which is a pull model, so plan on polling the agreement endpoints with a cursor for change detection unless the vendor confirms an event surface for the tenant. | | Events posture | Polling | | Rate limits | Documented and specific: 15 requests per second with a burst of 30, returning a rate-exceeded error beyond that. No separate daily or monthly quota is published. | | Objects | Analyze: agreements (create/import, retrieve, list), agreement documents via pre-signed URL, and metadata - AI-extracted smart values, terms including custom user-generated values, types, tags and parent-child hierarchy. Finalize: agreements and requests, agreement detail fields, attachments, versions, and owner assignment by user ID. | ## 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 | Finalize agreement or request, plus its agreement detail fields | | Requirement | Tenant | | Notes | Which agreement detail fields exist, and which are mandatory, is tenant-configured per template. Owner assignment is by user ID, so composerID resolves a LinkSquares user rather than passing an email string. | | Mapping | Detail | | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Canonical to destination | title, counterparty, start\_date, end\_date, value | | Target | Analyze agreement record; supplied values land alongside the AI-extracted smart values | | Requirement | Required | | Notes | Agreement type and tags are required on import. Supplied metadata is stored as a user-generated value rather than overwriting the AI's extraction, so precedence per field has to be agreed with the customer. | | Mapping | Detail | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Canonical to destination | intent\_id | | Target | A dedicated custom term in Analyze, or a dedicated agreement detail field in Finalize | | Requirement | Tenant required | | Notes | There is no first-class external-ID field on the agreement; vendor guidance is to store an external identifier as a custom term. Provision a text field of at least 64 characters before go-live, or the Intent ID has nowhere to live. | | Mapping | Detail | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Canonical to destination | defence\_file\_ref | | Target | Document uploaded via pre-signed URL, or an attachment on an existing Finalize agreement | | Requirement | Recommended | | Notes | Because upload is a second call, publishing is not atomic: treat metadata-created-but-file-missing as a retryable state and key retries on the Intent ID so a retry does not create a second agreement. | | Mapping | Detail | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Canonical to destination | intent\_id | | Target | Read the agreement, matched on the stored Intent ID | | Requirement | Read | | Notes | With no documented webhooks, reconciliation is a scheduled poll - budget it against the 15 requests/second ceiling and use cursor pagination rather than re-walking the repository. | Agreement detail fields in Finalize and terms in Analyze are per-tenant configuration, so the field carrying the Intent ID must be provisioned by the customer's administrator before publishing is enabled. Agreement types and tags are also tenant-defined and required on Analyze import, so a valid vocabulary has to be agreed per customer. Commercially, the Finalize public API reads as an add-on rather than part of the base subscription - confirm the customer has actually licensed API access before scoping. API keys are per user per company, so provision a dedicated service account. ## 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.