> You are reading the Docusign Developer Documentation. For clean Markdown of any page, append .md to the page URL. > > Documentation indexes by section: > - APIs and SDKs: https://docusign.docs.buildwithfern.com/docs/llms.txt > - Platform 101: https://docusign.docs.buildwithfern.com/platform/llms.txt > - Extension Apps: https://docusign.docs.buildwithfern.com/extension-apps/llms.txt > - Docusign CLI: https://docusign.docs.buildwithfern.com/docusign-cli/llms.txt > > Authentication (OAuth, JWT Grant, M2M): https://docusign.docs.buildwithfern.com/platform/auth > Webhooks and Connect: https://docusign.docs.buildwithfern.com/platform/webhooks > > OpenAPI specifications: https://docusign.docs.buildwithfern.com/openapi.json > MCP server: https://docusign.docs.buildwithfern.com/_mcp/server # Manifest reference > Complete reference for the Docusign CLI manifest file. Describes all properties for custom fields, custom agreement types, and standard agreement type extensions. The `agreement-manager-manifest.json` file defines your Agreement Manager configuration, including custom fields, custom agreement types, and extensions to standard agreement types. The Docusign CLI uses this file to configure Agreement Manager in bulk when you run the [upload](/docusign-cli/configure-agreement-types-and-fields/upload-package) command. A complete example manifest file is provided in [Create a package](/docusign-cli/configure-agreement-types-and-fields/create-package). ## Manifest properties The following table describes the top-level properties of the manifest file. | Property | Description | Required | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------- | | `version` | Semantic version of your manifest (for example, `1.0.0`). | Yes | | `defaultLocale` | Default language locale. Currently only `en` is supported. | Yes | | `namespace` | Unique identifier for your custom fields package. Use a reverse-domain format that includes a version suffix (for example, `com.yourcompany.custom.fields@1.0.0`). | Yes | | `standardAgreementTypes` | Array of standard agreement types to extend with additional standard fields and custom field mappings. | Yes | | `customAgreementTypes` | Array of custom agreement types to create in Agreement Manager. | Yes | | `fields` | Array of custom field definitions. | Yes | | `metadata` | Information about the manifest, such as the author, description, and version history. | No | The following example shows the top-level structure of a manifest file with abbreviated array contents: ```text { "version": "1.0.0", "defaultLocale": "en", "namespace": "com.example.manufacturing@1.0.0", "standardAgreementTypes": [ ... ], "customAgreementTypes": [ ... ], "fields": [ ... ], "metadata": { "createdAt": "2025-01-06T00:00:00Z", "updatedAt": "2025-01-06T00:00:00Z", "version": "1.0.0", "author": "Manufacturing Team", "description": "Custom fields for manufacturing and supplier agreements", "tags": ["manufacturing", "supplier", "consulting"], "lastManifestHash": "" } } ``` ## Define custom fields Custom fields are defined in the `fields` array. Each object in the array defines one custom field and its AI extraction configuration. #### fields array properties | Property | Description | Required | Allowed values | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `key` | Unique identifier for the field. Must start with the `C_` prefix (uppercase C), followed by a letter, underscore (\_), or dollar sign (\$), then any combination of letters, digits, underscores, or dollar signs (for example, `C_MyField`, `C_$special`). This value must not duplicate any standard field `key`. | Yes | A valid identifier string starting with `C_` | | `displayName` | Display name for the field in the Agreement Manager UI. This value must not duplicate any standard field `displayName`. | Yes | Any string | | `category` | Category used to organize the field in Agreement Manager. | No. Defaults to `GeneralCategory`. | `FinancialCategory, GeneralCategory, HumanResourcesCategory, LegalAndComplianceCategory, LifecycleCategory, OtherCategory, PaymentCategory, RenewalCategory, TerminationCategory` | | `fieldType` | Data type of the field. | Yes | `String, Number, DateTime, Dropdown` | | `customExtractionEnabled` | Specifies whether AI extraction is enabled for this field. Up to 50 custom fields and custom agreement types combined can have AI extraction enabled, with no more than 15 custom agreement types. | Yes | `true` or `false` | | `aiDefinition` | Prompt used to train the AI model to extract the field value from an agreement. A clear and specific description produces better extraction accuracy. Required when `customExtractionEnabled` is `true`. | Conditional | Any string | | `examples` | Training examples that help the AI learn how to extract this field. Provide 3 - 5 examples using full paragraphs in `exampleText` for best accuracy. Required when `customExtractionEnabled` is `true`. | Conditional | Object with an en array of `{ "exampleText": "...", "confirmedValue": "..." }` objects | | `dropdownOptions` | Options for fields with `fieldType` set to `Dropdown`. If `customExtractionEnabled` is `true` for a dropdown field, provide a clear description for each option to improve extraction accuracy. | Required if `fieldType` is `Dropdown` | Array of `{ "name": "...", "description": "..." }` objects | ### Custom field limits and constraints * The maximum number of custom fields is 300. * Up to 50 custom fields can have AI extraction enabled, or a combination of custom fields and custom agreement types can be used (for example, 35 custom fields and 15 custom types). No more than 15 custom agreement types can have AI extraction enabled. * Custom field names and labels must not duplicate standard field names and labels. * Every custom field newly defined in the manifest must be referenced in `fields.customFields` of at least one agreement type (standard or custom) in the manifest. This validation does not apply to fields already in the custom catalog. * After you have added custom fields and [uploaded](/docusign-cli/configure-agreement-types-and-fields/upload-package) the package, you cannot delete the custom fields from the account. If you no longer wish to use a custom field, you can remove it from any agreements that include it. See [Field removal from custom agreement types](/docusign-cli/configure-agreement-types-and-fields/manifest-reference#field-removal-from-custom-agreement-types) and [Field removal from standard agreement types](/docusign-cli/configure-agreement-types-and-fields/manifest-reference#field-removal-from-standard-agreement-types). ### Example custom field definition ```text { "key": "C_Subprocessor", "displayName": "Subprocessor", "fieldType": "String", "category": "GeneralCategory", "customExtractionEnabled": true, "aiDefinition": "The name of the third-party service provider (subprocessor) authorized to process or access customer data on behalf of the primary service provider under the agreement.", "examples": { "en": [ { "exampleText": "The Service Provider may use approved subprocessors to support the delivery of services under this Agreement. As of the Effective Date, the approved Subprocessor for cloud hosting and infrastructure services is MICROSOFT AZURE.", "confirmedValue": "MICROSOFT AZURE" } ] } } ``` ## Define custom agreement types Custom agreement types are defined in the `customAgreementTypes` array. Each object in the array defines one custom agreement type, its field mappings, and its AI extraction configuration. #### customAgreementTypes array properties | Property | Description | Required | Allowed values | | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------- | ------------------------------------------------------------------------------------ | | `key` | Unique identifier for the agreement type. Must start with the `C_` prefix (uppercase C), followed by a letter, underscore (\_), or dollar sign (\$), then any combination of letters, digits, underscores, or dollar signs (for example, `C_SupplierAgreement`). This value must not duplicate any standard agreement type `key`. | Yes | A valid identifier string starting with `C_` | | `displayName` | Display name for the agreement type in the Agreement Manager UI. This value must not duplicate any standard agreement type `displayName`. | Yes | Any string | | `category` | Category used to organize the agreement type in Agreement Manager. | No. Defaults to `Miscellaneous`. | `BusinessServices, HumanResources, Miscellaneous, OtherDocuments` | | `customExtractionEnabled` | Specifies whether AI extraction is enabled for this agreement type. No more than 15 custom agreement types can have AI extraction enabled. Combined with custom fields, the total AI extraction limit is 50. | Yes | `true` or `false` | | `aiDefinition` | Prompt used to train the AI model to identify and classify agreements of this type. A clear and specific description produces better extraction accuracy. Required when `customExtractionEnabled` is `true`. | Conditional | Any string | | `fields` | Defines the additional fields mapped to the custom agreement type. Contains two arrays:- `additionalStandardFields`: Standard field display names from `standard-catalog.json` - `customFields`: Custom field display names defined in the manifest. By default, every custom agreement type includes the six standard fields Title, Parties, Execution Date, Effective Date, Status, and Line of Business. Do not add these to `additionalStandardFields`. | Yes | Object with `additionalStandardFields` and `customFields` string arrays | | `docs` | Array of training document filenames used to train the AI to identify this agreement type. Required when `customExtractionEnabled` is true. Provide at least 5 and up to 10 example agreements for best accuracy. Files must exist in `{workspace}/{project}/agreement-manager/files/train/`. | Conditional | Array of filenames present in `{workspace}/{project}/agreement-manager/files/train/` | ### Custom agreement type limits and constraints * The maximum number of custom agreement types is 200. * No more than 15 custom agreement types can have AI extraction enabled. * Custom agreement type names and labels must not duplicate standard agreement type names and labels. * Training documents are required for custom agreement types with `customExtractionEnabled` set to true. Training documents must exist in the `{workspace}/{project}/agreement-manager/files/train/ directory`. * All labels in `fields.customFields` must match a custom field label defined in the manifest's `fields` array. ### Field removal from custom agreement types You can remove standard and custom fields from a custom agreement type by deleting them from the `additionalStandardFields` or `customFields` array. If you have previously [uploaded](/docusign-cli/configure-agreement-types-and-fields/upload-package) a package that included the fields in the agreement type, you must upload again to apply the changes. You cannot remove the default standard fields included in every custom agreement type: Title, Parties, Execution Date, Effective Date, Status, and Line of Business. > **Note** > > Removing a field from an agreement type does not remove it from your account. The field will still be available to include in other agreement types. After uploading a package in which fields have been removed: 1. [Test](/docusign-cli/test-agreement-customizations) the changes. 2. [Deploy](/docusign-cli/deploy-agreement-customizations) the changes to your production account and any additional accounts where the field removals should be applied. 3. [Reprocess](/docusign-cli/reprocess-agreements) any previously ingested agreements in the applicable accounts to remove the fields from the extracted agreement data. ### Example custom agreement type definition ```text "customAgreementTypes": [ { "key": "C_InternshipOfferLetter", "displayName": "Internship Offer Letter", "category": "HumanResources", "customExtractionEnabled": true, "aiDefinition": "An agreement outlining the terms and conditions of an internship, including the intern's role, start and end dates, stipend or compensation, reporting manager, and other employment terms.", "fields": { "additionalStandardFields": [], "customFields": ["Intern Name", "Intern Role", "Internship Start Date", "Internship End Date", "Stipend", "Reporting Manager"] }, "docs": [ "Internship Offer Letter - Charles.pdf", "Internship offer Letter - Bob.pdf", "Internship Offer Letter - John.pdf", "Internship offer Letter - Sarah.pdf" ] } ] ``` ## Extend standard agreement types Standard agreement types are Agreement Manager's out-of-the-box agreement types, each with a predefined set of standard fields. You can extend standard agreement types in the manifest by mapping additional standard fields and custom fields to them in the `standardAgreementTypes` array. Use `standard-catalog.json` (generated by the [get catalog](/docusign-cli/configure-agreement-types-and-fields/retrieve-standard-and-custom-catalogs#retrieve-current-configuration) command) as your reference when configuring standard agreement type extensions. The catalog contains the exact `key` and `displayName` values you must use, as well as the default standard fields already mapped to each type. #### standardAgreementTypes array properties | Property | Description | Required | Allowed values | | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ----------------------------------------------------------------------------- | | `key` | Unique identifier of the standard agreement type. Copy this value exactly from `standard-catalog.json`. The value must match the standard agreement type name exactly; a mismatch causes a validation error. | Yes | Name of the standard agreement type as it appears in `standard-catalog.json` | | `displayName` | Display name of the standard agreement type shown in the Agreement Manager UI. Copy this value exactly from `standard-catalog.json`. The value must match the standard agreement type label exactly; a mismatch causes a validation error. | Yes | Label of the standard agreement type as it appears in `standard-catalog.json` | | `fields` | Defines the additional fields mapped to the standard agreement type. Contains two arrays:- `additionalStandardFields`: Standard field display names from `standard-catalog.json` - `customFields`: Custom field display names defined in the manifest. Do not include fields already mapped by default to the agreement type in `additionalStandardFields`. Adding a default field again causes a validation error. Only include custom field display names in `customFields`. Adding a standard field there causes a validation error. | Yes | Object with `additionalStandardFields` and `customFields` string arrays | ### Limits and constraints for extending standard agreement types * All labels in `fields.additionalStandardFields` must exist in the standard catalog. * All labels in `fields.customFields` must meet one of these requirements: * Matches a custom field label defined in the manifest's `fields` array * Exists in the account's custom catalog. You can use the [get catalog](/docusign-cli/configure-agreement-types-and-fields/retrieve-standard-and-custom-catalogs#retrieve-current-configuration) command to retrieve the custom catalog. * Do not add a field that is already mapped by default to the agreement type. This causes a validation error. ### Field removal from standard agreement types You can remove additional standard fields and custom fields from a standard agreement type by deleting them from the `additionalStandardFields` or `customFields` array. If you have previously [uploaded](/docusign-cli/configure-agreement-types-and-fields/upload-package) a package that included the fields in the agreement type, you must upload again to apply the changes. The default [standard fields](https://support.docusign.com/s/document-item?bundleId=pqz1702943441912\&topicId=smm1727282189861.html) mapped to each agreement type cannot be changed or removed. > **Note** > > Removing a field from an agreement type does not remove it from your account. The field will still be available to include in other agreement types. After uploading a package in which fields have been removed: 1. [Test](/docusign-cli/test-agreement-customizations) the changes. 2. [Deploy](/docusign-cli/deploy-agreement-customizations) the changes to your production account and any additional accounts where the field removals should be applied. 3. [Reprocess](/docusign-cli/reprocess-agreements) any previously ingested agreements in the applicable accounts to remove the fields from the extracted agreement data. ### Example standard agreement type extension ```text { "key": "ConsultingDocumentData", "displayName": "Consulting Agreement", "fields": { "additionalStandardFields": ["Renewal Notice Date"], "customFields": ["Project Code"] } } ``` ## Frequently asked questions ### What happens if a custom field or custom agreement type defined in the manifest already exists in Agreement Manager? The CLI does not create a duplicate. Instead, it updates the existing field or agreement type by overwriting its properties - such as the description, category, extraction settings, or training examples - with the values defined in the manifest. Field mappings defined in the manifest are also applied to the existing agreement type. ### Can I remove custom fields or custom agreement types from an account using the manifest? No. Once a custom field or custom agreement type is added to an Agreement Manager account, the CLI cannot remove it. Standard agreement types and standard fields also cannot be removed from Agreement Manager. ### Can I remove additional fields from an agreement type after they have been mapped? Yes. To remove additional fields from an agreement type, remove the corresponding field labels from the `additionalStandardFields` or `customFields` arrays for that agreement type in the manifest, then run `ds agm upload` again. Note that the default standard fields mapped to each agreement type cannot be changed or removed. ### What are the limits on the number of custom fields and custom agreement types with AI extraction enabled? Up to 50 custom fields and custom agreement types combined can have AI extraction enabled. Within that limit, no more than 15 custom agreement types can have AI extraction enabled. For example, valid distributions include 50 custom fields and 0 custom types, 35 custom fields and 15 custom types, or 40 custom fields and 10 custom types. A distribution of 34 custom fields and 16 custom types is not allowed. ### What manifest issues can cause validation errors when I try to upload a package? The CLI validates the manifest before uploading and returns an error if required properties are missing or incorrect, if `key` or `displayName` values for standard agreement types do not match the standard catalog, if custom field or agreement type names conflict with standard names, if referenced training documents are missing from the `agreement-manager/files/train/` directory, or if field label references in `additionalStandardFields` or `customFields` do not resolve correctly. Correct the reported issue in the manifest and run the [upload](/docusign-cli/configure-agreement-types-and-fields/upload-package) command again. ## Next steps * Learn about [uploading a package](/docusign-cli/configure-agreement-types-and-fields/upload-package), including what happens after a successful upload and how to resolve validation errors. * [Test agreement customizations](/docusign-cli/test-agreement-customizations) to validate AI extraction accuracy before deploying to production. * [Deploy agreement customizations](/docusign-cli/deploy-agreement-customizations) to a production account or to multiple accounts.