Finalize API Technical Overview – LinkSquares Help Center

Overview

Connect your systems with LinkSquares Finalize by using the LinkSquares Finalize API to allow legal teams to collaborate with their stakeholders (procurement, business managers, sales) without requiring those stakeholders to leave their preferred applications.

The Finalize API enables customers to build integrations to:

Draft or request agreements from other systems while ensuring legal teams will be able to receive and work on these requests from Finalize.
View agreement status and version updates from other systems as legal teams work on agreements within Finalize.

Finalize API Functionality Highlights

Create agreements and requests by sending documents and data from third-party systems.
Upload attachments to existing agreements.
Download agreement versions and attachments.
View the current status of any agreement.
Retrieve information about and approve tasks.

To learn more about the available Finalize API endpoints, reference our article on the LinkSquares API Overview.

Setup and Access

To learn more about setting up and installing the API key, reference our article on Managing API Keys.

LinkSquares Finalize Data Model

The following sections outline several core data models and concepts. These core data models and concepts, along with a basic understanding of Finalize, will help users understand how to interact with the Finalize API. To learn more about Finalize, reference our articles on LinkSquares Finalize.

Templates

Users can have templates to represent different types of agreements (such as a Non-Disclosure Agreement or a Master Services Agreement). Templates define the information that needs to be populated to create a particular type of agreement. Templates are defined by the legal team.

There are three kinds of templates supported by the Finalize API:

Draft (Our Paper)
Intake (3rd Party Paper)
Request Forms (Our Paper)

For all agreements, the user must answer a set of agreement detail fields, which are metadata questions about the agreement. This data does not enter the agreement itself but helps to categorize and contextualize the agreement.

In Draft (Our Paper) agreements, Finalize will merge data provided by the user to populate predefined variables (tokens) in the template to generate the agreement.
Intake (3rd Party Paper) workflows require the user to upload a third-party agreement for review by legal.
Request Forms (Our Paper) consist of agreement detail fields only.

Template Type	Agreement Detail Fields	Additional Information
Draft (Our Paper)	Required	Tokens
Intake (3rd Party Paper)	Required	File Upload
Request Forms (Our Paper)	Required	N/A

Agreements

Agreements represent a contract being worked on by legal. Agreements are created from a template. Users are able to track the states, versions, and attachments of agreements as well as view the associated agreement detail fields and responses.

Any business manager can draft an agreement by filling out the necessary agreement detail fields, and if needed, uploading an intake agreement or providing values to populate tokens of a Draft (Our Paper) agreement.

Agreement Detail Fields

Agreement detail fields capture agreement metadata. Agreement metadata is structured data that contextualizes the agreement but does not reside in the agreement itself. This data may need to remain separate from the agreement for ease of access and categorization.

The types of agreement detail fields are:

Text
Paragraph
Date
Numbers
Multiple-selection
Single-selection
URL

Note:

Date fields must be in the ISO8601 format.

Tokens

Tokens are “mail merge” fields that are configured in the template for an agreement. When creating a new agreement from a template, users will be able to input data for all available tokens.

For example, an NDA template may require #[EFFECTIVE_DATE]# and #[COUNTERPARTY_NAME]# to be filled in. In order to create the agreement, the user must submit valid values for each of these tokens.

Each token has a designated data type that the value must match. The available data types are:

Text field
Text area
Date
Clause
Multiple-selection
Single-selection

Note: Date tokens must be in the ISO8601 format.

At this time, all standard token types are supported by the Finalize API. Pricing table tokens are not currently supported by the Finalize API.

Agreement Versions

Agreement versions are the actual files that represent each version of an agreement. Versions can be stored in either DOCX or PDF format. The Finalize API provides the ability to upload a new agreement version and download an agreement version file in its original format.

Attachments

Attachments, also known as support files, can be uploaded to an agreement.

The supported file types are as follows.

DOC*	DOCX	PDF	XLS	XLSX	PPT	PPTX
MP3	GIF	JPEG	JPG	PNG	BMP	SVG
TXT	MP4	MPEG	MPG	MOV	WMV	AVI

Note: Within API code, file extensions should be referenced using all lowercase letters.

The Finalize API provides the ability to upload or download attachments for an existing agreement.

Agreement Statuses

Agreement statuses represent what stage of the contract lifecycle a given agreement is in. The following table outlines the agreement statuses available within the Finalize API. A description of each status, their identifier within the Finalize API, and what other statuses each status can transition to is also provided.

Agreement Status	Description	Finalize API Identifier	Statuses To Transition To
Request Pending	An agreement request starts in this status if the Request Form has been filled out but an initial draft of the agreement has not been started.	request_pending	counterparty_review internal_review ready_for_signature paused_request_pending
Internal Review	An agreement is being reviewed internally or needs to be reviewed internally before being sent to the counterparty.	internal_review	counterparty_review paused_counterparty_review done
Counterparty Review	An agreement has been sent to the counterparty for review or the agreement needs to be sent to the counterparty for review.	counterparty_review	internal_review done paused_internal_review
Ready for Signature	An agreement will automatically move into this status once all parties approve the agreement and no other tasks or approvals are outstanding.	ready_for_signature	internal_review counterparty_review out_for_signature partially_signed done paused_ready_for_signature
Out for Signature	An agreement has been sent to the required counterparties for signature.	out_for_signature	internal_review counterparty_review ready_for_signature partially_signed fully_signed done paused_out_for_signature
Partially Signed	An agreement has been signed by some but not all of the required parties.	partially_signed	internal_review counterparty_review ready_for_signature out_for_signature fully_signed done paused_partially_signed
Fully Signed	An agreement has been signed by all required parties. Agreements will automatically move to this status when all required signatures have been collected.	fully_signed	N/A
Done	The agreement is complete but does not require signature.	done	N/A
Paused	The work on the agreement has been paused until further notice. If work resumes on this agreement, it will return to the status it was in before being paused.	paused_request_pending paused_internal_review paused_counterparty_review paused_ready_for_signature paused_out_for_signature paused_partially _signed	A paused agreement can only be transitioned to the status the agreement was in prior to being paused A paused agreement can only transition to a status with the corresponding identifier. For example, paused_request_pending can only transition to request_pending.