> For the complete documentation index, see [llms.txt](https://docs.samesystem.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.samesystem.dev/business-guides/data-models/contract.md). # Contract {% hint style="info" %} Only available in API v2. We have different contract model in API v1. However, for user and contract integrations, we strongly recommend using **API v2**, and this guide therefore describes user creation using API v2 only. {% endhint %} A contract represents an employment record, which is a time-bound employment relationship, also known as “terms of employment”. It is defined by: | Field: | Description: | | ----------- | ------------------------------------------------------------------------ | | `startDate` | Start date for this contract. | | `endDate` | End date for this contract. It can be nullable for an open-ended contact | The contract record contains employment-specific attributes like title, salary, contract hours, payroll number and department. It is possible to add custom fields to the contracts record and retrieve these in the API. **Characteristics:** * Defined by a date range. * Contains employment specific data. * Multiple contracts per employee are allowed. * Future contracts are allowed. * Past contracts are allowed. **Constraints:** * Only one contract can be active at any point in time.\ Start date and end date defines the active contract. A nullable end date means that this is an open-ended contract. * Parallel employment (multiple active contracts) will be possible as this is under development, but currently not described in this document. * Contracts must not overlap for the same employee. These situations will always require a new contract: * [x] New hire. * [x] Change of title. * [x] Change of department. * [x] Change of contract hours. * [x] Change of salary (any). These changes will affect schedule, calculations of payroll data and vacation, which is the reason why a new contract must be created with a new start date, from when the change becomes active. ### Employment status The user will have a derived status based on contracts.
Condition:Derived status:
No contracts at allUser not employed
Current date within a contractActive employment
Only past contractsFormer employee
Only future contractsHired (future start)
Past contract(s) and future contractRehire scheduled (future start) with a gap between past and future contracts
### Update from title based settings In title based settings, you can add extra salary fields, like percentage, amount and standard contract hours.
If you use the API to insert a new contract with the same title as the previous one, the system will copy values from the previous contract into these extra salary fields. If you need to insert a new contract with the same title and need to adjust the extra salary fields, you will need to add the information to the request body. If you use the API to insert a new contract with a different title than the previous one, the system will copy the default values the title based settings into these extra salary fields on the contract. ### API settings These settings can only be set by SameSystem. Contact the Integration Team if you need to change these settings. #### Fallback end date on contract If no end date is provided during contract insert or upsert, the system automatically sets it to the day before the next contract’s start date to prevent overwriting future contracts. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.samesystem.dev/business-guides/data-models/contract.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.