> This page is for API, version 2026-01-01 (Stable) (default). > For other versions, use one of these documentation indexes: > - 2026-01-01 (Stable) (default): https://developer.deel.com/api/stable/llms.txt > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://developer.deel.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://developer.deel.com/_mcp/server. # Amendment Settings and Effective Date > Retrieve and interpret contract amendment validation settings and effective date rules ## Retrieve contract information for amendment To retrieve available amendment settings, you first need the contract ID. Use the [List of contracts](/api/reference/endpoints/contracts/get-contracts) endpoint to retrieve your contracts. You can filter and sort the list to find the correct `contract_id`. Use the returned `contract_id` in the next step. ```shell curl --location -g --request GET '{{host}}/rest/contracts?limit=2&sort_by=worker_name&order_direction=desc' \ --header 'Authorization: Bearer {{token}}' ``` ## Retrieve amendment settings Once you have a contract ID, use it to retrieve valid amendment settings using [Get Amendment validation settings](/api/reference/endpoints/eor-amendments/get-contract-amendments-validation-settings) endpoint. These are based on the contract and country-specific rules. Use the `contract_id` path parameter to fetch available data points and rules. This returns all configurable data points and validation logic. ```shell curl --location -g --request GET '{{host}}/rest/eor/contracts/{{contract_id}}/amendments/validation/settings' \ --header 'Authorization: Bearer {{token}}' ``` The validation settings endpoint accepts optional `employment_state` query parameter to provide more accurate validation rules based on intended state/region for the employee. Use this when you need to amend the `employment_state` and need validation rules specific to the new state. For example, hourly rate minimum wages can vary by state. If not provided, the current contract's employment state is used for validation rules. #### Example with query parameters ```shell curl --location -g --request GET '{{host}}/rest/eor/contracts/{{contract_id}}/amendments/validation/settings?employment_state=CA' \ --header 'Authorization: Bearer {{token}}' ``` ### Example response ```json [ { "data_point": "notice_period_type", "rules": [ { "nullable": false, "is_editable": true, "possible_options": [ "STANDARD", "CUSTOM" ], "requires": { "employment_type": "FULL_TIME" } }, { "nullable": false, "is_editable": true, "possible_options": [ "STANDARD", "CUSTOM" ], "requires": { "employment_type": "PART_TIME" } } ] } ] ``` ## Understand how amendment settings work The response for `amendment-settings` includes a list of configurable contract fields. Each field is described by a `data_point` object that defines how it can be changed. Key elements: * Each `data_point` represents an attribute in the contract that may be amended. * The `requires` object defines conditions that must be met for the change to be allowed. All fields in `requires` must match either the current contract or the amendment request. * Numeric fields include `min` and `max` constraints. * `possible_options` lists the allowed values for the data point. * `is_editable` indicates if the field can be updated. If a field is not editable, the reason is not returned in the API. It may be due to country rules, amendment restrictions, or other pending amendments, for example, currency. * `additional_details` may include validation notes or business constraints. * Date fields can include `min_date` and `max_date`, formatted as `YYYY-MM-DD`, for example, `2025-06-17`. ### Examples of amendment rules These examples show how the API applies rules to control when you can update specific fields. #### Require a field in the contract or request You can only apply this rule if the contract or amendment request includes `contract_term: "DEFINITE"`. ```json { "nullable": false, "is_editable": true, "min_date": "2025-06-02", "requires": { "contract_term": "DEFINITE" } } ``` #### Employment type restriction You can set `employment_type` to `FULL_TIME` only if `contract_term` is `INDEFINITE`. ```json { "nullable": false, "is_editable": true, "possible_options": ["FULL_TIME"], "requires": { "contract_term": "INDEFINITE" } } ``` #### Numeric constraints This rule allows minimum and maximum values when `employment_type` is `FULL_TIME`. ```json { "nullable": false, "is_editable": true, "min": 6, "max": 12, "requires": { "employment_type": "FULL_TIME" } } ``` #### Use external validation This rule indicates that complete validation requires calling the [validate-amendment](/api/reference/endpoints/eor-amendments/validate-eor-amendments) endpoint. When `external_validation: true`, you can either: * Call the [validate amendment](/api/reference/endpoints/eor-amendments/validate-eor-amendments) endpoint for server-side validation. * Skip validation entirely and let the create/update endpoints return validation errors. ```json { "nullable": false, "is_editable": true, "external_validation": true } ``` ## Amendment effective date The effective date is the date when the amendment becomes active. It defines when the changes take effect and when they appear in payroll, invoices, or other downstream processes. Different amendment fields trigger different business logic. Based on what you are changing, Deel dynamically calculates a valid effective date range. To support this flexibility, Deel exposes the [Effective Date Limitations](/api/reference/endpoints/eor-amendments/get-contract-amendment-effective-date-limitations) API that you need to call to retrieve the valid effective date limits for a specific amendment. This ensures that: * Your system always works with the correct date limits. * Deel applies the correct validations automatically based on the amendment content, helping you avoid false validations or user errors. * You can choose to show or disable the effective date field in your UI. * You can apply validation rules or pre-fill values based on internal workflows. > **Note** > > Amendments on contracts that are not yet active can't have an effective date. ### Fetching effective date limits You must fetch the effective date limitations: * Immediately after creating or updating an amendment. * Before setting or submitting the effective date. * Before confirming the amendment, if any changes were made after fetching the last effective date. > **Warning** > > The valid effective date range is based on the specific changes in the amendment. Always fetch the date limits only after all changes to the amendment are finalized. ### Status behavior by effective date | Effective date | What happens | | ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | Effective date in the future | The amendment gets an `upcoming` status. It won’t affect contract values immediately. | | Effective date today or in the past | The amendment becomes `active` as soon as it’s processed and signed. | | Effective date not provided | The amendment becomes `active` immediately after all parties sign. Deel uses the date when all parties confirm the amendment as the effective date. | > **Note** > > Amendments in `upcoming` status do not affect payroll, invoicing, or contract terms until they are activated by Deel’s internal job on the effective date. ### High-level flow The diagram below shows how the effective date influences the amendment lifecycle, from creation to activation: ```mermaid sequenceDiagram participant Client participant DeelAPI as Deel API Client->>DeelAPI: Create Amendment (POST) DeelAPI-->>Client: Amendment Flow Returned Client->>DeelAPI: Fetch Effective Date Limits (GET) DeelAPI-->>Client: Date Limits (min/max/default/hidden/disabled) Note over Client: Show Calendar UI (optional) Client->>DeelAPI: Update Amendment (PATCH with effective_date) Client->>DeelAPI: Confirm Amendment Note over DeelAPI: Cron activates amendment on effective_date ``` ### UI behavior: is_hidden and is_disabled When you fetch effective date limitations, the response includes flags that guide you in rendering the field in your UI. | Field | Client-side behavior | | ------------- | ------------------------------------------------------------------------------------------------------------------------- | | `is_hidden` | (Optional) Suggests that the field may be hidden from the user interface. You may decide whether to follow this behavior. | | `is_disabled` | If true, the field should not be editable. You must use `default_effective_date`. | > **Note** > > If your use case involves applying an automatic default effective date, such as aligning it with the start of the payroll cycle, hiding the field might improve user experience. ### Effective date validation rules The validation logic for effective dates ensures that all amendments respect configuration limits, providing flexibility while preventing invalid data entry. | Scenario | Requirement | | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | `is_disabled = true` and `is_hidden = true` | Field must not be included in the request. | | `is_disabled = true` and default date is present | Field must exactly match the default effective date. | | `min_effective_date`, `max_effective_date`, or `default_effective_date` is present | A valid effective date must be provided and must fall within range. | | No limits defined | Field is optional. System will automatically set it to when all parties confirm the amendment. | Validation runs at two points: * On create or update. Runs when you send the effective date in the request payload. * On confirmation. The effective date is always validated when the amendment is confirmed, regardless of its draft status. > **Note** > > Draft amendments are validated only when you provide an effective date.