Creates a new contract in Zenskar. Contracts represent revenue agreements with customers and serve as the foundation for billing, invoicing, and revenue recognition.
A contract defines commercial terms including pricing models, service periods, and billing cycles. Required fields are customer_id, name, status, currency, start_date, and at least one phase—all other fields are optional.
Documentation Index
Fetch the complete documentation index at: https://docs2.zenskar.com/llms.txt
Use this file to discover all available pages before exploring further.
Human-readable name for the contract. Used for identification and reporting purposes.
Contract status. Only 'active' and 'draft' are accepted. Other statuses (expired, paused) are managed via dedicated endpoints.
draft, active, paused, expired, disputed Three-letter ISO 4217 currency code for all monetary amounts in this contract (e.g., 'USD', 'EUR', 'GBP'). Must match customer's billing currency or be explicitly configured.
Date when the contract becomes active and billing begins. Must be in ISO 8601 format. Used as the basis for billing cycle calculations and revenue recognition.
The unique identifier of the customer who is party to this contract. Customer must exist in the system before contract creation.
Optional contract ID to use. If not provided, one will be generated automatically.
Detailed description of the contract terms, scope, or special conditions. Displayed in contract details and reports.
Optional list of tags for categorizing and filtering contracts (e.g., ['enterprise', 'annual', 'discounted']). Useful for reporting and segmentation.
Optional date when the contract expires. If not provided, contract continues indefinitely until manually terminated. Must be after start_date. Used for automatic expiration and renewal calculations.
Reference date for billing cycle calculations. When set, all billing cycles align to this date regardless of contract start. Useful for ensuring consistent billing dates across multiple contracts.
When true, billing cycles always end on the last day of the month, adjusting for varying month lengths. Commonly used for monthly subscriptions billed on the last day.
Optional reference to a predefined plan template. When provided, contract inherits phases, products, and pricing from the plan. Useful for standardized offerings.
Flexible key-value store for organization-specific metadata. Can include fields like sales_rep, deal_id, region, or any custom data needed for reporting and integrations.
List of contract phases defining distinct periods with different terms, products, or pricing. Common use cases include trial periods, promotional pricing, or stepped pricing models. Phases must not overlap and must fall within contract date boundaries.
Defines contract renewal behavior. Currently only 'do_not_renew' is supported—contracts must be manually renewed or replaced. Additional renewal options coming soon.
renew_with_default_contract, renew_with_existing, do_not_renew URL to external contract document, signed agreement, or related resource. Useful for maintaining references to legal documents stored in external systems.
When true and customer has a parent relationship, invoices are sent to the parent customer instead. Used for hierarchical billing scenarios like subsidiaries or franchises.
Optional customer ID who will receive and pay invoices for this contract, if different from the contract customer. Used when one entity uses services but another pays for them.
Metadata about the originating system or process that created this contract. Commonly includes fields like 'system', 'opportunity_id', or 'contract_number' for integration tracking and audit trails.
Contract created successfully
Unique identifier for this contract
Human-readable name for the contract. Used for identification and reporting purposes.
Current status of the contract (e.g., active, draft, expired, terminated). System automatically updates to 'expired' when end_date is reached.
draft, active, paused, expired, disputed Three-letter ISO 4217 currency code for all monetary amounts in this contract (e.g., 'USD', 'EUR', 'GBP').
Timestamp when this contract was created in the system. Used for audit trails and reporting.
Timestamp of the last modification to this contract. Updates whenever any field or related entity changes.
Unique identifier of the customer who is party to this contract.
Complete customer details including name, contact information, and billing preferences. The customer who is party to this contract.
Detailed description of the contract terms, scope, or special conditions.
List of tags for categorizing and filtering contracts. Useful for reporting and segmentation.
Date when the contract became or will become active. Billing and revenue recognition calculations start from this date.
Date when the contract expires. Null indicates an indefinite contract that continues until manually terminated.
Organization-specific metadata stored as key-value pairs. Can include fields like sales_rep, deal_id, region, or any custom data needed for reporting and integrations.
Metadata about the originating system or process that created this contract. Used for integration tracking and audit trails.
Reference date for billing cycle calculations. When set, billing cycles align to this date regardless of contract start date.
When true, billing cycles always end on the last day of the month, adjusting for varying month lengths.
Reference to the plan template used to create this contract, if applicable.
Defines contract renewal behavior. Currently only 'do_not_renew' is supported—contracts must be manually renewed or replaced.
renew_with_default_contract, renew_with_existing, do_not_renew List of contract phases defining distinct periods with different terms, products, or pricing. Sorted chronologically by start date.
Customer details for the invoice payer, if different from the contract customer. Used when one entity uses services but another pays for them.
The contract phase that is currently active based on today's date. Null if no phase is active or contract hasn't started.
URL to external contract document, signed agreement, or related resource.
When true and customer has a parent relationship, invoices are sent to the parent customer instead.
Customer ID who will receive and pay invoices for this contract, if different from the contract customer.