EOR Contract Amendment API

The EOR contract amendment API lets you update contract terms through a structured approval process that follows predefined compliance rules.

An amendment is a change to one or more contract terms, referred to as data points, such as employment type, job title, scope, or salary. Instead of modifying the original contract document, the amendment is issued as a separate addendum to the employment agreement. The contract entity in the database, including its ID, remains the same. Only specific values, like salary, are updated with a new effective date.

You or Deel can initiate an amendment. The process includes multiple steps and requires approval from both you and the employee. Modification and approval rules vary based on the amended data point and country-specific regulations.

Amendment flows

Amendments can be initiated by you or or by Deel. The steps an amendment goes through are different depending on who initiates it.

Scenario when you requests an amendment

Follow these steps to create and process an amendment programmatically.

1. Create an amendment with the Create amendment endpoint.
2. Update fields as needed with the Update amendment endpoint.
3. Confirm the amendment with the Confirm amendment endpoint.

After you confirm the amendment:

• If the change is applied immediately, the API response includes the updated status.
• If the change requires approval, Deel reviews it and sends it to the employee for signing. The employee then reviews the amendment and signs it with the Sign amendment (employee) endpoint.

Scenario when Deel requests an amendment

Follow these steps to process an amendment requested by Deel.

Follow these steps to process an amendment requested by Deel.

1. Deel creates an amendment.
2. You review the amendment and either:

• Accept it with the Accept amendment (client) endpoint.
• Cancel, it with the Cancel amendment.

3. If you accept the amendment, the employee reviews and signs it with the Sign amendment (employee) endpoint.

When does deel create amendments?

Deel may create amendments in the following cases:

• At your request. When you ask for a change that requires Deel involvement.
• To ensure compliance. When a contract update is needed to meet legal or regulatory requirements.
• For restricted changes. Some updates are only available through admin amendments due to system limitations or internal policies.

Webhook events

Webhooks are triggered at key stages of the amendment process and provide automatic updates on status changes.

Amendment types

Each amendment has a type that determines how it is processed. The type is returned in the response when creating or updating an amendment. It is based on the amendment settings and the data points being amended.

An amendment can have one of the following types:

• INSTANT: Activated immediately after you confirm it. No Deel review or employee signature is required.
• AUTOMATED: Activated once the employee signs it. Deel review is not required.
• LEGAL or OPS: Requires Deel review because at least one data point is set to require internal review. The difference between LEGAL and OPS is internal only and relates to how Deel conducts the review. For example, the review may involve document preparation. After Deel completes the review, the amendment is sent to the employee for review and signature. The amendment is activated once the employee signs it.
• DISABLED: Contains at least one data point that is restricted from being changed by the amendment settings.
• CUSTOM: Manually created by a Deel admin.

Examples

Example 1: Germany (instant amendment)

In this Germany example, both holidays (holiday increase) and timeOffType changes are instant. They are activated once the amendment becomes active.

The amendment type is INSTANT. In items, each data point also has INSTANT as its type:

1
{
2
  "type": "INSTANT",
3
  "items": [
4
    {
5
      "data_point": "holidays",
6
      "id": "59d9a2d5-9ea0-4f7f-8ac0-1db66e62d9fa",
7
      "item": "holidaysIncrease",
8
      "type": "INSTANT",
9
      "previous_value": "6",
10
      "new_value": "12"
11
    },
12
    {
13
      "data_point": "timeOffType",
14
      "id": "78743852-4dea-4b7c-bbac-44828a7d9b97",
15
      "item": "timeOffType",
16
      "type": "INSTANT",
17
      "previous_value": "STANDARD",
18
      "new_value": "SPECIFIC"
19
    }
20
  ]
21
}

Example 2: Greece (legal amendment)

For Greece, the same data points require Deel review because one of the items has the LEGAL type:

1
{
2
  "type": "LEGAL",
3
  "items": [
4
    {
5
      "data_point": "holidays",
6
      "id": "f783003f-777f-425a-9a14-faf6457b7585",
7
      "item": "holidaysIncrease",
8
      "type": "INSTANT",
9
      "previous_value": "6",
10
      "new_value": "10"
11
    },
12
    {
13
      "data_point": "timeOffType",
14
      "id": "d9dffd0a-6443-4992-9aa7-d859bd9d4d4d",
15
      "item": "timeOffType",
16
      "type": "LEGAL",
17
      "previous_value": "STANDARD",
18
      "new_value": "SPECIFIC"
19
    }
20
  ]
21
}

Retrieve contract information for amendment

To retrieve available amendment settings, you first need the contract ID. Use the List of 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.

$
curl --location -g --request GET '{{host}}/rest/v2/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 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.

$
curl --location -g --request GET '{{host}}/rest/v2/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

$
curl --location -g --request GET '{{host}}/rest/v2/eor/contracts/{{contract_id}}/amendments/validation/settings?employment_state=CA' \
>
--header 'Authorization: Bearer {{token}}'

Example response

1
[
2
  {
3
    "data_point": "notice_period_type",
4
    "rules": [
5
      {
6
        "nullable": false,
7
        "is_editable": true,
8
        "possible_options": [
9
          "STANDARD",
10
          "CUSTOM"
11
        ],
12
        "requires": {
13
          "employment_type": "FULL_TIME"
14
        }
15
      },
16
      {
17
        "nullable": false,
18
        "is_editable": true,
19
        "possible_options": [
20
          "STANDARD",
21
          "CUSTOM"
22
        ],
23
        "requires": {
24
          "employment_type": "PART_TIME"
25
        }
26
      }
27
    ]
28
  }
29
]

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".

1
{
2
    "nullable": false,
3
    "is_editable": true,
4
    "min_date": "2025-06-02",
5
    "requires": {
6
        "contract_term": "DEFINITE"
7
    }
8
}

Employment type restriction

You can set employment_type to FULL_TIME only if contract_term is INDEFINITE.

1
{
2
    "nullable": false,
3
    "is_editable": true,
4
    "possible_options": ["FULL_TIME"],
5
    "requires": { "contract_term": "INDEFINITE" }
6
}

Numeric constraints

This rule allows minimum and maximum values when employment_type is FULL_TIME.

1
{
2
    "nullable": false,
3
    "is_editable": true,
4
    "min": 6,
5
    "max": 12,
6
    "requires": { "employment_type": "FULL_TIME" }
7
}

Use external validation

This rule indicates that complete validation requires calling the validate-amendment endpoint. When external_validation: true, you can either:

• Call the validate amendment endpoint for server-side validation.

• Skip validation entirely and let the create/update endpoints return validation errors.

  1
  {
  2
      "nullable": false,
  3
      "is_editable": true,
  4
      "external_validation": true
  5
  }

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 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.

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.

Status behavior by effective date

High-level flow

The diagram below shows how the effective date influences the amendment lifecycle, from creation to activation:

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.

Effective date validation rules

The validation logic for effective dates ensures that all amendments respect configuration limits, providing flexibility while preventing invalid data entry.

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.

Create a draft amendment

Create a new draft amendment by specifying the contract_id. You can include all, some, or none data points you plan to amend. This allows you to start with a basic amendment and add more details later.

$
curl --location -g --request POST '{{host}}/rest/v2/eor/contracts/{{contract_id}}/amendments' \
>
--header 'Authorization: Bearer {{token}}' \
>
--header 'Content-Type: application/json' \
>
--data-raw '{
>
    "data": {
>
    }
>
}'

OR

$
curl --location -g --request POST '{{host}}/rest/v2/eor/contracts/{{contract_id}}/amendments' \
>
--header 'Authorization: Bearer {{token}}' \
>
--header 'Content-Type: application/json' \
>
--data-raw '{
>
    "data": {
>
        "time_off_type": "SPECIFIC",
>
        "holidays": 12,
>
        "employment_type": "PART_TIME"
>
    }
>
}'

Update existing draft amendment

Update an existing draft amendment by including the amendment_id returned when the amendment was created. You can add additional data points, modify existing ones, or set the effective date. This endpoint allows you to build your amendment incrementally.

$
curl --location -g --request PATCH '{{host}}/rest/v2/eor/contracts/{{contract_id}}/amendments/{{amendment_id}}' \
>
--header 'Authorization: Bearer {{token}}' \
>
--header 'Content-Type: application/json' \
>
--data-raw '{
>
    "data": {
>
        "time_off_type": "SPECIFIC",
>
        "holidays": 12,
>
        "employment_type": "PART_TIME",
>
        "effective_date": "2025-08-01",
>
    }
>
}'

Amendment validation approaches

You have these options for validating amendment data points:

• Client-side validation: Use the validation rules from the amendment settings endpoint to validate fields before submission.
• Server-side validation: Use the validate amendment endpoint to validate fields before submission.
• Hybrid approach: Use client-side validation for basic fields and server-side validation for complex fields with external_validation: true.
• No pre-validation: Skip validation and let the create/update endpoints return validation errors.

The amendment submission endpoint always performs validation and returns errors, so pre-validation is optional. However, for fields with external_validation: true, you may want to validate beforehand to provide better user experience or to perform AI-job-scope checks and job categorization.

Hybrid approach

The hybrid approach combines both validation methods for optimal performance and user experience:

• Use client-side validation for fields with external_validation: false to provide immediate feedback.
• Use server-side validation for fields with external_validation: true to get complete validation.

Validate amendment data points

Use the validate amendment endpoint to validate amendment data points before submission.

$
curl --location --request POST '{{host}}/rest/v2/eor/contracts/{{contract_id}}/amendments/validate-amendment' \
>
--header 'Authorization: Bearer {{token}}' \
>
--header 'Content-Type: application/json' \
>
--data-raw '{
>
    "data": {
>
        "job_title": "Senior Software Engineer",
>
        "scope": "Lead development of web applications"
>
    }
>
}'

Response format

The response includes validation results with field-specific error mapping:

1
{
2
  "data": {
3
    "is_valid": true,
4
    "validation_error": [],
5
    "disabled_amendments": [],
6
    "ai_job_scope_and_title_check": {
7
      "is_valid": true,
8
      "ai_scope_check_public_id": "9f9e086f-2195-4ced-a641-c62d5cd388fc"
9
    },
10
    "job_categorization": {
11
      "is_valid": true,
12
      "job_categorization_log_id": "366681cd-fe16-4be7-9e45-692a4bbc91c0",
13
      "job_category": "Software Engineer",
14
      "job_code": "214129"
15
    }
16
  }
17
}

Error response with field mapping

When validation fails, errors include a field parameter for easy frontend integration:

1
{
2
  "data": {
3
    "is_valid": false,
4
    "validation_error": [
5
      {
6
        "code": "AMENDMENT_ITEM_VALIDATION_FAILED",
7
        "message": "Scope exceeds maximum length of 20,000 characters",
8
        "field": "scope",
9
        "details": {
10
          "newValue": "Very long scope description...",
11
          "previousValue": "Short scope"
12
        }
13
      }
14
    ],
15
    "disabled_amendments": [],
16
    "ai_job_scope_and_title_check": null,
17
    "job_categorization": null
18
  }
19
}

Seniority ID

To amend seniority_id:

1. Retrieve the list of avaialble levels using the Get Seniority List endpoint.
2. Include the selected seniority_id in your amendment request.

Effective date limitations

Follow these steps to use effective date limitations:

1. Create an amendment using the Create Amendment endpoint endpoint.
2. Call the Get Effective Date Limitations endpoint.
3. Use the returned rules to set the effective date in the UI.
4. (Optional) If required, submit the amendment with an effective date.

AI job scope check and job categorization

AI review check

• When a job title/scope amendment is created or updated, an AI review check is triggered to ensure the new job title/scope aligns with the existing job description and responsibilities.
• You can trigger the validate amendment endpoint for the AI review check to be performed before creating/updating the job title/scope amendment.
• You can submit the amendment regardless of the AI review outcome, but if the AI review fails, the amendment will be flagged for manual review by Deel’s internal team.
• You will get ai_scope_check_public_id when using validate amendment endpoint if the AI review succeeds, which can be used to track the review status.
• You need to send this ai_scope_check_public_id in the amendment request so it won’t require any manual review.

1. Validate job title/scope values using the validate amendment endpoint:

1
{
2
  "url": "https://api.letsdeel.com/rest/v2/eor/contracts/{{contract_id}}/amendments/validate-amendment",
3
  "method": "POST",
4
  "headers": {
5
    "accept": "application/json",
6
    "Content-Type": "application/json",
7
    "Authorization": "Bearer {API_TOKEN}"
8
  },
9
  "body": {
10
    "data": {
11
      "job_title": "Senior Software Manager"
12
    }
13
  }
14
}

Response:

1
{
2
  "data": {
3
    "is_valid": true,
4
    "validation_error": [],
5
    "disabled_amendments": [],
6
    "ai_job_scope_and_title_check": {
7
      "is_valid": true,
8
      "ai_scope_check_public_id": "9f9e086f-2195-4ced-a641-c62d5cd388fc"
9
    },
10
    "job_categorization": null
11
  }
12
}

2. Create or update amendment request using ai_scope_check_public_id:

1
{
2
  "url": "https://api.letsdeel.com/rest/v2/eor/contracts/{{contract_id}}/amendments/{{amendment_id}}",
3
  "method": "PATCH",
4
  "headers": {
5
    "accept": "application/json",
6
    "Content-Type": "application/json",
7
    "Authorization": "Bearer {API_TOKEN}"
8
  },
9
  "body": {
10
    "job_title": "Senior Software Manager",
11
    "additional_info": {
12
      "ai_scope_check_public_id": "9f9e086f-2195-4ced-a641-c62d5cd388fc"
13
    }
14
  }
15
}

Job categorization with AI recommendations

• Job categorization is only available for specific countries. You can see the list of countries where job categorization is supported in the following table:

• Every time when a job title is amended, an AI job categorization is triggered to classify the new job title into a predefined job category and code.
• You can trigger the validate amendment endpoint for the AI job categorization to be performed before creating or updating the job title amendment.
• You can submit the amendment regardless of the AI job categorization outcome, but if the AI job categorization fails, the amendment will be flagged for manual review by Deel’s internal team.
• You will get job_categorization_log_id when using validate amendment endpoint if the AI job categorization succeeds, which can be used to track the review status.
• You will also get job_code and job_category along with job_categorization_log_id in the response if the AI job categorization succeeds.
• You need to send this job_categorization_log_id and job_code and job_category in create or update amendment request so it won’t require any manual review.

1. Validate job title value using the validate amendment endpoint:

1
{
2
  "url": "https://api.letsdeel.com/rest/v2/eor/contracts/{{contract_id}}/amendments/validate-amendment",
3
  "method": "POST",
4
  "headers": {
5
    "accept": "application/json",
6
    "Content-Type": "application/json",
7
    "Authorization": "Bearer {API_TOKEN}"
8
  },
9
  "body": {
10
    "data": {
11
      "job_title": "Senior Software Manager"
12
    }
13
  }
14
}

Response:

1
{
2
  "data": {
3
    "is_valid": true,
4
    "validation_error": [],
5
    "disabled_amendments": [],
6
    "ai_job_scope_and_title_check": {
7
      "is_valid": false,
8
      "message": "Job scope is too short"
9
    },
10
    "job_categorization": {
11
      "is_valid": true,
12
      "job_categorization_log_id": "366681cd-fe16-4be7-9e45-692a4bbc91c0",
13
      "job_category": "Manager, Software Development",
14
      "job_code": "13306011"
15
    }
16
  }
17
}

2. Create or update the amendment using job_categorization_log_id:

1
{
2
  "url": "https://api.letsdeel.com/rest/v2/eor/contracts/{{contract_id}}/amendments/{{amendment_id}}",
3
  "method": "PATCH",
4
  "headers": {
5
    "accept": "application/json",
6
    "Content-Type": "application/json",
7
    "Authorization": "Bearer {API_TOKEN}"
8
  },
9
  "body": {
10
    "job_title": "Senior Software Manager",
11
    "additional_info": {
12
      "job_categorization_log_id": "366681cd-fe16-4be7-9e45-692a4bbc91c0"
13
    },
14
    "job_category": "Manager, Software Development",
15
    "job_code": "13306011"
16
  }
17
}

When you trigger the validate amendment endpoint for job title amendments:

• In countries where job categorization is supported:
  • Both AI check and job categorization run.
  • You must send ai_scope_check_public_id and job_categorization_log_id together with job_code and job_category in the update amendment request to avoid manual review.
• In countries where job categorization is not supported:
  • Only AI check runs.

Update amendment with both ai_scope_check_public_id and job_categorization_log_id

Use this request to update an amendment with both the AI check and job categorization identifiers:

1
{
2
  "url": "https://api.letsdeel.com/rest/v2/eor/contracts/{{contract_id}}/amendments/{{amendment_id}}",
3
  "method": "PATCH",
4
  "headers": {
5
    "accept": "application/json",
6
    "Content-Type": "application/json",
7
    "Authorization": "Bearer {API_TOKEN}"
8
  },
9
  "body": {
10
    "job_title": "Senior Software Manager",
11
    "additional_info": {
12
      "ai_scope_check_public_id": "9f9e086f-2195-4ced-a641-c62d5cd388fc",
13
      "job_categorization_log_id": "366681cd-fe16-4be7-9e45-692a4bbc91c0"
14
    },
15
    "job_category": "Manager, Software Development",
16
    "job_code": "13306011"
17
  }
18
}

Validation errors and disabled amendments

Amendment requests can fail if validation rules are not met. In these cases, the API returns an error response that includes details about validation errors and disabled data points.

Standard error format

All error responses have been standardized to follow a consistent format, making them easier to interpret and integrate.

If your amendment request fails validation, the API returns an error response. The response includes details about the validation errors and disabled data points.

Each response includes a code and a message field, while the field attribute remains optional. This ensures that you can reliably handle errors while still receiving additional context, when available.

Mandatory fields:

Optional fields

Common amendment error codes

Error response examples

The following examples show the different types of validation and amendment errors you may encounter.

Request validation errors

These errors occur when the request payload fails general validation checks.

1
{
2
  "errors": [
3
    {
4
      "code": "VALIDATION_ERROR",
5
      "message": "Internal validation error occurred"
6
    }
7
  ]
8
}

General amendment errors

These errors indicate that the amendment request cannot proceed due to one or more issues.

1
{
2
    "errors": [
3
        {
4
            "message": "Amendment already in progress with ID: 5ea6c745-3f40-4fc8-864e-026ccae666e1",
5
            "code": "AMENDMENT_ERROR"
6
        }
7
    ]
8
}

Amendment field validation errors and disabled amendment

These errors appear when specific fields are invalid or disabled for the requested amendment.

1
{
2
    "errors": [
3
        {
4
            "message": "Job title is not enabled for white label API",
5
            "code": "AMENDMENT_ITEM_DISABLED",
6
            "field": "jobTitle"
7
        },
8
9
        {
10
            "message": "Minimum salary for United Kingdom is $30,312.07",
11
            "code": "AMENDMENT_ITEM_VALIDATION_FAILED",
12
            "field": "salary",
13
            "details": {
14
                "previousValue": "96000.0000",
15
                "newValue": "3000"
16
            }
17
        }
18
    ]
19
}

Amendment processing failed errors

These errors occur when an amendment cannot be updated or confirmed.

1
{
2
  "errors": [
3
    {
4
      "code": "AMENDMENT_UPDATE_FAILED",
5
      "message": "Failed to update amendment",
6
      "field": "amendment"
7
    }
8
  ]
9
}

1
{
2
  "errors": [
3
    {
4
      "code": "CHANGE_REQUEST_CONFIRMED",
5
      "message": "Change request is already confirmed",
6
      "field": "changeRequestId"    
7
    }
8
  ]
9
}

Amendment statuses

Amendments pass through multiple statuses from creation to completion. These statuses are returned in an array within the API response. Check the most recent status to determine the amendment’s current state.

Amendment status structure

Amendment statuses are hierarchical, meaning they can be read at multiple levels of detail. Each status has two key properties:

• NAME → Machine-readable identifier
• FRIENDLY_NAME → Human-readable label

Draft stage

Amendments that are still being prepared and can be modified.

Preparing documents stage

Statuses related to document preparation and internal review. Documents are being created, reviewed, or paused for input before signatures can begin. No action required by you in this case, fetch the amendments to get the latest status.

Signature stage

These statuses indicate the amendment is awaiting or in the process of being signed. Either it awaits Deel countersign or waiting for client or employee signature.

Active or upcoming stage

Statuses when an amendment is in effect or scheduled for the future.

Cancelled, rejected, or void stage

Statuses for amendments that were canceled, rejected, or voided.

How to read amendment statuses

Amendment statuses are structured in a hierarchical format, where each level provides increasing detail about the amendment’s progress.

1. Parent phase

• Represents the overall stage of the amendment, for example PREPARING_DOCUMENTS.
• Indicates the broad area of progress, such as document preparation, review, or approval.

2. Sub-step

• A more specific action within the parent phase, for example PREPARING_DOCUMENTS.AMENDMENT_REQUESTED.
• Helps identify what part of the larger process is currently active.

3. Detailed checkpoint

• Provides the most detailed level of the amendment’s status, for example PREPARING_DOCUMENTS.AMENDMENT_REQUESTED.SOW.PENDING_DOCUMENT_SUBMIT.
• Clarifies the current condition of the amendment, such as pending submission, under review, or awaiting approval.

Why this matters

• Each nested level gives increasing detail about the amendment’s progress.
• The high-level phase always represents the current overall state of the amendment, for example PREPARING_DOCUMENTS, ACTIVE, UPCOMING, or CANCELLED.
• Sub-steps and detailed checkpoints record the lifecycle progression of the amendment. This is useful for auditing, troubleshooting, and tracking how the amendment evolved over time.

Below is an example of an amendment status array from the API response. In this example:

• The amendment is in the PREPARING_DOCUMENTS phase.
• The request is logged as PREPARING_DOCUMENTS.AMENDMENT_REQUESTED.
• The amendment is waiting for Deel review (PREPARING_DOCUMENTS.AMENDMENT_REQUESTED.SOW.PENDING_DOCUMENT_SUBMIT). Further actions are required before it can proceed.

1
[
2
  {
3
    "name": "PREPARING_DOCUMENTS",
4
    "friendly_name": "PREPARING_DOCUMENTS",
5
    "_amendment_flow_status": {
6
      "created_at": "2025-03-19T17:15:02.053Z"
7
    }
8
  },
9
  {
10
    "name": "PREPARING_DOCUMENTS.AMENDMENT_REQUESTED",
11
    "friendly_name": "AMENDMENT_REQUESTED",
12
    "_amendment_flow_status": {
13
      "created_at": "2025-03-19T17:15:02.053Z"
14
    }
15
  },
16
  {
17
    "name": "PREPARING_DOCUMENTS.AMENDMENT_REQUESTED.SOW.PENDING_DOCUMENT_SUBMIT",
18
    "friendly_name": "AWAITING_REVIEW",
19
    "_amendment_flow_status": {
20
      "created_at": "2025-03-19T17:15:02.053Z"
21
    }
22
  }
23
]

Confirm an amendment

To confirm a draft amendment, use the contract_id and amendment_id. Only draft amendment can be confirmed.

After confirmation, the flow depends on the amendment type. If the type is instant, the amendment becomes active immediately. If it requires signatures, Deel or the employee must approve it first.

$
curl --location -g --request PUT '{{host}}/rest/v2/eor/contracts/{{contract_id}}/amendments/{{amendment_id}}/confirm' \
>
--header 'Authorization: Bearer {{token}}'

Cancel an amendment

To cancel an amendment, use the contract_id and amendment_id. You can cancel an amendment any time before the employee signs it. After cancellation, you can delete it if needed.

$
curl --location -g --request DELETE '{{host}}/rest/v2/eor/contracts/{{contract_id}}/amendments/{{amendment_id}}' \
>
--header 'Authorization: Bearer {{token}}'

Download an amendment PDF

Retrieve the download URL for the Statement of Work (Employee Agreement, EA) of a confirmed amendment. The URL is available only after the amendment is confirmed and the contract is in progress.

$
curl --location -g --request GET '{{host}}/rest/v2/eor/contracts/{{contract_id}}/amendments/{{amendment_id}}/pdf' \
>
--header 'Authorization: Bearer {{token}}'

Accept an amendment

Use this endpoint to accept an amendment submitted by a Deel admin.

After acceptance, the amendment either becomes active immediately or moves to the signature step, depending on its type.

$
curl --location -g --request PUT '{{host}}/rest/v2/eor/contracts/{{contract_id}}/amendments/{{amendment_id}}/accept' \
>
--header 'Authorization: Bearer {{token}}'

Sign an approved amendment

An employee can sign an amendment approved by both the client and admin. After signing, the amendment becomes active.

$
curl --location -g --request PUT '{{host}}/rest/v2/eor/contracts/{{contract_id}}/amendments/{{amendment_id}}/sign' \
>
--header 'Authorization: Bearer {{token}}'

Retrieve the list of amendments

Retrieve all amendments for a specific contract.

$
curl --location -g --request GET '{{host}}/rest/v2/eor/contracts/{{contract_id}}/amendments' \
>
--header 'Authorization: Bearer {{token}}'

Retrieve a specific amendment

Retrieve details of a specific amendment

$
curl --location -g --request GET '{{host}}/rest/v2/eor/contracts/{{contract_id}}/amendments/{{amendment_id}}' \
>
--header 'Authorization: Bearer {{token}}'

Custom amendment items

Custom amendment items are used when you request changes that:

• Involve data points not supported or not available in the standard amendment flow.
• Modify general employment agreement wording for active contracts.
• Include other ad-hoc or unique change requests not covered by standard items.

Once the amendment is confirmed, these custom items are reviewed by internal Deel teams.

Lifecycle and behavior

• Custom amendment items are part of an amendment, just like standard amendment items, and therefore follow the same overall amendment lifecycle:
  created → confirmed → reviewed

• Custom items also have a separate internal lifecycle. They have their own statuses and can be approved or rejected independently of the overall amendment.

• If an amendment includes both standard and custom items, and only the custom items are rejected, the amendment may still proceed with the standard changes.

• Exception: If the amendment contains only custom items and they are rejected, the entire amendment will be rejected.

Custom amendment item types

If a specific data point is not available in the standard amendment flow, you can use one of the predefined custom item types to request the change. These types represent the area of the contract or employment terms you want to amend:

Here is a request example for custom items with amendment:

$
curl --location -g --request POST '{{host}}/rest/v2/eor/contracts/{{contract_id}}/amendments' \
>
--header 'Authorization: Bearer {{token}}' \
>
--header 'Content-Type: application/json' \
>
--data-raw '{
>
    "data": {
>
        "time_off_type": "SPECIFIC",
>
        "holidays": 12,
>
        "employment_type": "PART_TIME",
>
        "custom": [
>
          {
>
            "description": "Change start date to the 1st of November 2026",
>
            "type": "START_DATE"
>
          },
>
          {
>
            "description": "Add fixed allowances to the contract with these details.",
>
            "type": "FIXED_ALLOWANCES"
>
          },
>
          {
>
            "description": "Change the contract term to Part time",
>
            "type": "OTHER"
>
          }
>
        ]
>
    }
>
}'

Amendment general rules and settings

Amendments follow certain global rules and configuration options. These settings define how specific data points behave across different contract types and countries.

Probation period settings

The probation_period data point supports multiple rule types and constraints, depending on the contract type and country-specific settings.

Rule-based configuration

Set the probation period based on a rule and cap value:

1
{
2
  "rule": "ONE_QUARTER_OF_CONTRACT_DURATION",
3
  "cap": 100,
4
  "time_unit": "DAY"
5
}

Tenure-based configuration

Other configurations define probation periods based on the employee’s expected duration of employment:

1
{
2
  "minEmploymentDuration": 6,
3
  "maxEmploymentDuration": 12,
4
  "employmentDurationType": "MONTH",
5
  "probationPeriod": 90
6
}

Employment terms configuration

• For INDEFINITE contracts, the probation period must be between 90 and 180 days, regardless of whether the employment type is FULL_TIME or PART_TIME.
• For DEFINITE contracts, the minimum probation period is 20 days. The maximum value is calculated dynamically.

Dynamic calculation for definite contracts

When the contract term is DEFINITE, the API calculates the maximum probation period using contract_duration_in_days and the country-specific rule eor_country_data.max_probation_type_for_definite.

Available rule types:

HALF_OF_CONTRACT_DURATION

• Maximum probation period is half the contract duration. Example: A 180-day contract allows up to 180 / 2 = 90 days.

ONE_QUARTER_OF_CONTRACT_DURATION

• Maximum probation period is one-quarter of the contract duration. Example: A 180-day contract allows up to 180 / 4 = 45 days.

ONE_THIRD_OF_CONTRACT_DURATION (Default)

• If no country rule is defined, the fallback is one-third of the contract duration. Example: A 180-day contract allows up to 180 / 3 = 60 days.

Cap on maximum probation period

The API may apply a cap to limit the maximum probation period, even when it uses a duration-based rule.

• If additional_details includes a cap value, the system uses the lower value between the calculated maximum and the cap.
• The cap applies only when the probation period is based on:
  • HALF_OF_CONTRACT_DURATION
  • ONE_QUARTER_OF_CONTRACT_DURATION
  • ONE_THIRD_OF_CONTRACT_DURATION

Example:

If the contract duration is 180 days and the rule is HALF_OF_CONTRACT_DURATION, the calculated maximum is 90 days. However, if a cap of 60 days exists in additional_details, the maximum probation period is limited to 60 days.

This ensures that the probation period for DEFINITE contracts remains proportional to the contract length while complying with country-specific regulations and additional constraints.

Notice period settings

The notice period defines how far in advance either party must give notice to end the contract. Different rules apply depending on probation and contract configuration.

Settings for notice period after probation rules

The notice_period_after_probation data point follows specific rules based on employment_type and notice_period_type.

Notice period general rules

These rules apply only when notice_period_type is set to CUSTOM.

• The min and max notice period values range from 0 to 12 weeks.
• Rules vary for FULL_TIME and PART_TIME employees.
• The notice period before probation must always be shorter than the notice period after probation.

Tenure-based notice period

Only notice_period_after_probation supports tenure-based rules. These rules depend on the contract duration and define different notice period values for different tenure ranges.

Example rule definition

1
{
2
  "data_point": "notice_period_after_probation",
3
  "rules": [
4
    {
5
      "nullable": true,
6
      "min": 0,
7
      "max": 12,
8
      "is_editable": true,
9
      "requires": {
10
        "notice_period_type": "CUSTOM",
11
        "employment_type": "FULL_TIME"
12
      },
13
      "additional_details": {
14
        "tenure_based_rules": [
15
          {
16
            "maxEmploymentDuration": 24,
17
            "minEmploymentDuration": 12,
18
            "noticeValue": 30,
19
            "employmentDurationType": "MONTH"
20
          },
21
          {
22
            "maxEmploymentDuration": 34,
23
            "minEmploymentDuration": 25,
24
            "noticeValue": 50,
25
            "employmentDurationType": "MONTH"
26
          }
27
        ],
28
        "time_unit": "WEEK",
29
        "note": "Notice period before probation should be less than notice period after probation"
30
      }
31
    },
32
    {
33
      "nullable": false,
34
      "min": 0,
35
      "max": 12,
36
      "is_editable": true,
37
      "requires": {
38
        "notice_period_type": "CUSTOM",
39
        "employment_type": "PART_TIME"
40
      },
41
      "additional_details": {
42
        "time_unit": "WEEK",
43
        "note": "Notice period before probation should be less than notice period after probation"
44
      }
45
    }
46
  ]
47
}

How to create and process amendment with examples

1. Retrieve amendment settings

$
curl --location --request GET '{{host}}/rest/v2/eor/contracts/{{contract_id}}/amendments/validation/settings' \
>
--header 'accept: application/json' \
>
--header 'Content-Type: application/json' \
>
--header 'Authorization: Bearer {{token}}' \
>
}'

Response:

1
{
2
    "data": [
3
        {
4
            "data_point": "CONTRACT_TERM",
5
            "rules": [
6
                {
7
                    "nullable": false,
8
                    "is_editable": true,
9
                    "possible_options": [
10
                        "DEFINITE",
11
                        "INDEFINITE"
12
                    ]
13
                }
14
            ]
15
        },
16
        {
17
            "data_point": "CUSTOM",
18
            "rules": [
19
                {
20
                    "nullable": false,
21
                    "is_editable": true,
22
                    "possible_options": [
23
                        "START_DATE",
24
                        "END_DATE",
25
                        "BENEFITS",
26
                        "PROBATION_PERIOD",
27
                        "VARIABLE_COMPENSATIONS",
28
                        "INCENTIVE_PLAN",
29
                        "SALARY",
30
                        "FIXED_ALLOWANCES",
31
                        "JOB_TITLE",
32
                        "SENIORITY_ID",
33
                        "SENIORITY_DATE",
34
                        "JOB_CODE",
35
                        "JOB_CATEGORY",
36
                        "JOB_SCOPE",
37
                        "EMPLOYMENT_TYPE",
38
                        "PERSONAL_DATA",
39
                        "OTHER"
40
                    ]
41
                }
42
            ]
43
        },
44
        {
45
            "data_point": "EMPLOYMENT_TYPE",
46
            "rules": [
47
                {
48
                    "nullable": false,
49
                    "is_editable": true,
50
                    "possible_options": [
51
                        "FULL_TIME"
52
                    ]
53
                }
54
            ]
55
        }
56
    ]
57
}

2. Create amendment

$
curl --location POST '{{host}}/rest/v2/eor/contracts/374xe7e/amendments/' \
>
--header 'accept: application/json' \
>
--header 'Content-Type: application/json' \
>
--header 'Authorization: Bearer {{token}}' \
>
--data '{
>
    "data": {
>
    }
>
}'

Response

1
{
2
    "data": {
3
        "id": "993f6533-e941-47a3-962d-f871359076ff",
4
        "effective_date": null,
5
        "salary": "96000.0000",
6
        "employment_type": "FULL_TIME",
7
        "seniority_id": 1,
8
        "job_title": "Chief Quality Liaison",
9
        "time_off_type": "STANDARD",
10
        "probation_period_type_for_definite": null,
11
        "document_type": "SOW_EA",
12
        "holidays": 25,
13
        "probation_period": 180,
14
        "scope": "Chief Quality Liaison",
15
        "employee_nationality": "PH",
16
        "employment_state": null,
17
        "start_date": "2025-08-05T20:15:05.872Z",
18
        "end_date": null,
19
        "work_hours_per_week": "40.00",
20
        "sick_leave_days": null,
21
        "type": "OPS",
22
        "created_at": "2025-08-29T10:31:54.514Z",
23
        "updated_at": "2025-08-29T10:31:54.539Z",
24
        "requested_by": 2856213,
25
        "is_hrx_action_needed": false,
26
        "legal_context": null,
27
        "rejection_context": null,
28
        "void_deadline": null,
29
        "void_deadline_type": null,
30
        "notice_period_type": null,
31
        "notice_period_after_probation": "5",
32
        "notice_period_during_probation": "1",
33
        "notice_period_time_unit": "WEEK",
34
        "currency": "USD",
35
        "is_effective_date_updated": false,
36
        "description": null,
37
        "work_schedule_id": null,
38
        "work_schedule_rules_version": null,
39
        "source": "PUBLIC_API",
40
        "job_category": null,
41
        "job_code": null,
42
        "seniority_date": null,
43
        "custom_items": [],
44
        "amendment_statuses": [
45
            {
46
                "name": "DRAFT",
47
                "friendly_name": "DRAFT",
48
                "amendment_flow_status": {
49
                    "created_at": "2025-08-29T10:31:54.552Z"
50
                }
51
            }
52
        ],
53
        "items": []
54
    }
55
}

2.1 (Optional) Update the amendment using id from the response, if needed

$
curl --location PATCH '{{host}}/rest/v2/eor/contracts/374xe7e/amendments/993f6533-e941-47a3-962d-f871359076ff' \
>
--header 'accept: application/json' \
>
--header 'Content-Type: application/json' \
>
--header 'Authorization: Bearer {{token}}' \
>
--data '{
>
    "data": {
>
        "probation_period": 20
>
    }
>
}'

Response

1
{
2
    "data": {
3
        "id": "993f6533-e941-47a3-962d-f871359076ff",
4
        "effective_date": null,
5
        "salary": "96000.0000",
6
        "employment_type": "FULL_TIME",
7
        "seniority_id": 1,
8
        "job_title": "Chief Quality Liaison",
9
        "time_off_type": "STANDARD",
10
        "probation_period_type_for_definite": null,
11
        "document_type": "SOW_EA",
12
        "holidays": 25,
13
        "probation_period": 20,
14
        "scope": "Chief Quality Liaison",
15
        "employee_nationality": "PH",
16
        "employment_state": null,
17
        "start_date": "2025-08-05T20:15:05.872Z",
18
        "end_date": null,
19
        "work_hours_per_week": "40.00",
20
        "sick_leave_days": null,
21
        "type": "AUTOMATED",
22
        "created_at": "2025-08-29T10:31:54.514Z",
23
        "updated_at": "2025-08-29T10:41:10.880Z",
24
        "requested_by": 2856213,
25
        "is_hrx_action_needed": false,
26
        "legal_context": null,
27
        "rejection_context": null,
28
        "void_deadline": null,
29
        "void_deadline_type": null,
30
        "notice_period_type": null,
31
        "notice_period_after_probation": "5",
32
        "notice_period_during_probation": "1",
33
        "notice_period_time_unit": "WEEK",
34
        "currency": "USD",
35
        "is_effective_date_updated": false,
36
        "description": null,
37
        "work_schedule_id": null,
38
        "work_schedule_rules_version": null,
39
        "source": "PUBLIC_API",
40
        "job_category": null,
41
        "job_code": null,
42
        "seniority_date": null,
43
        "custom_items": [],
44
        "amendment_statuses": [
45
            {
46
                "name": "DRAFT",
47
                "friendly_name": "DRAFT",
48
                "amendment_flow_status": {
49
                    "created_at": "2025-08-29T10:31:54.552Z"
50
                }
51
            }
52
        ],
53
        "items": [
54
            {
55
                "data_point": "PROBATION_PERIOD",
56
                "id": "a643c866-66dc-4809-bc42-0d8b418bdc2b",
57
                "item": "PROBATION_PERIOD_DECREASE",
58
                "type": "AUTOMATED",
59
                "previous_value": "180",
60
                "new_value": "20"
61
            }
62
        ]
63
    }
64
}

2.2 (Optional) Use the amendment id to fetch the effective date limits. If you support it, display a calendar using the date limits and flags returned in the response

$
curl --location GET 'https://api-gateway.deel.training/rest/v2/eor/contracts/mdyyevp/amendments/993f6533-e941-47a3-962d-f871359076ff/effective-date-limitations' \
>
--header 'Authorization: Bearer {API_TOKEN}'

Response

$
{
>
  "data": {
>
    "is_hidden": false,
>
    "is_disabled": false,
>
    "min_effective_date": "2025-07-01",
>
    "max_effective_date": "2025-12-31",
>
    "default_effective_date": "2025-08-29T00:00:00.000+00:00",
>
    "message": "The effective date should align with the payroll cycle."
>
  }
>
}

2.3 Set the effective date by calling the update amendment endpoint, using the id from the response

$
curl --location PATCH '{{host}}/rest/v2/eor/amendments/374xe7e/' \
>
--header 'accept: application/json' \
>
--header 'Content-Type: application/json' \
>
--header 'Authorization: Bearer {{token}}' \
>
--data 
$
'{
>
    "data": {
>
        "effective_date": "2025-09-30",
>
        "probation_period": 20
>
    }
>
}'

Response

1
{
2
    "data": {
3
        "id": "993f6533-e941-47a3-962d-f871359076ff",
4
        "effective_date": "2025-09-30T00:00:00.000Z",
5
        "salary": "96000.0000",
6
        "employment_type": "FULL_TIME",
7
        "seniority_id": 1,
8
        "job_title": "Chief Quality Liaison",
9
        "time_off_type": "STANDARD",
10
        "probation_period_type_for_definite": null,
11
        "document_type": "SOW_EA",
12
        "holidays": 25,
13
        "probation_period": 20,
14
        "scope": "Chief Quality Liaison",
15
        "employee_nationality": "PH",
16
        "employment_state": null,
17
        "start_date": "2025-08-05T20:15:05.872Z",
18
        "end_date": null,
19
        "work_hours_per_week": "40.00",
20
        "sick_leave_days": null,
21
        "type": "AUTOMATED",
22
        "created_at": "2025-08-29T10:31:54.514Z",
23
        "updated_at": "2025-08-29T10:41:10.880Z",
24
        "requested_by": 2856213,
25
        "is_hrx_action_needed": false,
26
        "legal_context": null,
27
        "rejection_context": null,
28
        "void_deadline": null,
29
        "void_deadline_type": null,
30
        "notice_period_type": null,
31
        "notice_period_after_probation": "5",
32
        "notice_period_during_probation": "1",
33
        "notice_period_time_unit": "WEEK",
34
        "currency": "USD",
35
        "is_effective_date_updated": false,
36
        "description": null,
37
        "work_schedule_id": null,
38
        "work_schedule_rules_version": null,
39
        "source": "PUBLIC_API",
40
        "job_category": null,
41
        "job_code": null,
42
        "seniority_date": null,
43
        "custom_items": [],
44
        "amendment_statuses": [
45
            {
46
                "name": "DRAFT",
47
                "friendly_name": "DRAFT",
48
                "amendment_flow_status": {
49
                    "created_at": "2025-08-29T10:31:54.552Z"
50
                }
51
            }
52
        ],
53
        "items": [
54
            {
55
                "data_point": "PROBATION_PERIOD",
56
                "id": "a643c866-66dc-4809-bc42-0d8b418bdc2b",
57
                "item": "PROBATION_PERIOD_DECREASE",
58
                "type": "AUTOMATED",
59
                "previous_value": "180",
60
                "new_value": "20"
61
            }
62
        ]
63
    }
64
}

3. Confirm the amendment using the id from the response

$
curl --location --request POST '{{host}}/rest/v2/eor/contracts/mdyyevp/amendments/993f6533-e941-47a3-962d-f871359076ff/confirm' \
>
--header 'accept: application/json' \
>
--header 'Authorization: Bearer {{token}}'

Response

1
{
2
    "data": {
3
        "id": "993f6533-e941-47a3-962d-f871359076ff",
4
        "effective_date": "2025-09-30T00:00:00.000Z",
5
        "salary": "96000.0000",
6
        "employment_type": "FULL_TIME",
7
        "seniority_id": 1,
8
        "job_title": "Chief Quality Liaison",
9
        "time_off_type": "STANDARD",
10
        "probation_period_type_for_definite": null,
11
        "document_type": "SOW_EA",
12
        "holidays": 25,
13
        "probation_period": 20,
14
        "scope": "Chief Quality Liaison",
15
        "employee_nationality": "PH",
16
        "employment_state": null,
17
        "start_date": "2025-08-05T20:15:05.872Z",
18
        "end_date": null,
19
        "work_hours_per_week": "40.00",
20
        "sick_leave_days": null,
21
        "type": "AUTOMATED",
22
        "created_at": "2025-08-29T10:31:54.514Z",
23
        "updated_at": "2025-08-29T10:41:10.880Z",
24
        "requested_by": 2856213,
25
        "is_hrx_action_needed": false,
26
        "legal_context": null,
27
        "rejection_context": null,
28
        "void_deadline": null,
29
        "void_deadline_type": null,
30
        "notice_period_type": null,
31
        "notice_period_after_probation": "5",
32
        "notice_period_during_probation": "1",
33
        "notice_period_time_unit": "WEEK",
34
        "currency": "USD",
35
        "is_effective_date_updated": false,
36
        "description": null,
37
        "work_schedule_id": null,
38
        "work_schedule_rules_version": null,
39
        "source": "PUBLIC_API",
40
        "job_category": null,
41
        "job_code": null,
42
        "seniority_date": null,
43
        "custom_items": [],
44
        "amendment_statuses": [
45
            {
46
              "name": "PREPARING_DOCUMENTS.AMENDMENT_REQUESTED.EA",
47
              "friendly_name": "EA",
48
              "amendment_flow_status": {
49
                "created_at": "2025-03-25T11:32:52.963Z"
50
              }
51
            },
52
            {
53
              "name": "PREPARING_DOCUMENTS.AMENDMENT_REQUESTED.EA.  PENDING_DOCUMENT_SUBMIT",
54
              "friendly_name": "AWAITING_REVIEW",
55
              "amendment_flow_status": {
56
                "created_at": "2025-03-25T11:32:52.963Z"
57
              }
58
            },
59
            {
60
              "name": "PREPARING_DOCUMENTS.AMENDMENT_REQUESTED.SOW",
61
              "friendly_name": "SOW",
62
              "amendment_flow_status": {
63
                "created_at": "2025-03-25T11:32:52.963Z"
64
              }
65
            },
66
            {
67
              "name": "PREPARING_DOCUMENTS.AMENDMENT_REQUESTED.SOW. PENDING_DOCUMENT_SUBMIT",
68
              "friendly_name": "AWAITING_REVIEW",
69
              "amendment_flow_status": {
70
                "created_at": "2025-03-25T11:32:52.963Z"
71
              }
72
            },
73
            {
74
              "name": "PREPARING_DOCUMENTS.AMENDMENT_REQUESTED.CUSTOM_REVIEW",
75
              "friendly_name": "CUSTOM_REVIEW",
76
              "amendment_flow_status": {
77
                "created_at": "2025-03-25T11:32:52.963Z"
78
              }
79
            },
80
            {
81
              "name": "PREPARING_DOCUMENTS.AMENDMENT_REQUESTED.CUSTOM_REVIEW.       CUSTOM_SKIPPED",
82
              "friendly_name": "CUSTOM_SKIPPED",
83
              "amendment_flow_status": {
84
                "created_at": "2025-03-25T11:32:52.963Z"
85
              }
86
            },
87
            {
88
              "name": "PREPARING_DOCUMENTS.AMENDMENT_REQUESTED",
89
              "friendly_name": "AMENDMENT_REQUESTED",
90
              "amendment_flow_status": {
91
                "created_at": "2025-03-25T11:32:52.963Z"
92
              }
93
            },
94
            {
95
              "name": "PREPARING_DOCUMENTS",
96
              "friendly_name": "PREPARING_DOCUMENTS",
97
              "amendment_flow_status": {
98
                "created_at": "2025-03-25T11:32:52.963Z"
99
              }
100
            }
101
        ],
102
        "items": [
103
            {
104
                "data_point": "PROBATION_PERIOD",
105
                "id": "a643c866-66dc-4809-bc42-0d8b418bdc2b",
106
                "item": "PROBATION_PERIOD_DECREASE",
107
                "type": "AUTOMATED",
108
                "previous_value": "180",
109
                "new_value": "20"
110
            }
111
        ]
112
    }
113
}

4. Wait for the amendment to be reviewed. You can monitor its status using the following endpoint

$
curl --location GET '{{host}}/rest/v2/eor/contracts/mdyyevp/amendments/993f6533-e941-47a3-962d-f871359076ff' \
>
--header 'accept: application/json' \
>
--header 'Authorization: Bearer {{token}}'

Or you can use the webhook to get the status of the amendment

1
{
2
  "data": {
3
    "meta": {
4
      "event_type": "eor.amendment.status.updated",
5
      "event_type_id": "de688244-7869-46db-8ac7-00083965cc9b",
6
      "organization_id": "9c09a153-1418-4127-8c44-e99483e7c321",
7
      "organization_name": "20TT65OV",
8
      "tracking_id": "d09a72b0002191b65de3a453d177f1a7"
9
    },
10
    "resource": {
11
      "amendment_flow_id": "116fdec2-d8b6-4c64-82d9-089cccf92731",
12
      "organization_id": "9c09a153-1418-4127-8c44-e99483e7c321",
13
      "status": "EOR_AMENDMENT_V2_CLIENT_ACTIVE"
14
    }
15
  },
16
  "timestamp": "2025-02-07T12:36:16.360Z"
17
}

To get link to download the EA document:

$
curl --location GET '{{host}}/rest/v2/eor/contracts/mdyyevp/amendments/993f6533-e941-47a3-962d-f871359076ff/pdf' \
>
--header 'accept: application/json' \
>
--header 'Authorization: Bearer {{token}}'

Response

1
{
2
  "data": {
3
    "url": "{{host}}/eor-experience-dev/amendment_documents/fb4a3959-0a93-4dd9-9b46-7f1af60b2bbd.pdf?AWSAccessKeyId=TEST_ACCESS_KEY&Expires=1673158576&Signature=TEST_SIGNATURE"
4
  }
5
}

If you want to cancel the amendments, you can fo it as long as it is not active. Use the following call:

$
curl --location --request DELETE '{{host}}/rest/v2/eor/contracts/mdyyevp/amendments/993f6533-e941-47a3-962d-f871359076ff' \
>
--header 'accept: application/json' \
>
--header 'Authorization: Bearer {{token}}'

Response

1
{
2
    "data": {
3
        "success": true
4
    }
5
}

5. Once its review by Deel, the employee needs to sign it

$
curl --location --request POST '{{host}}/rest/v2/eor/contracts/mdyyevp/amendments/993f6533-e941-47a3-962d-f871359076ff/sign' \
>
--header 'accept: application/json' \
>
--header 'Authorization: Bearer {{token}}'

If the amendment requires countersignature by Deel, it will be reviewed by our internal team.

Once signed, the amendment will either become active immediately or be scheduled to take effect on the specified effective date