When a delete workflow is executed, MineOS makes an API call to the URL set in the Delete URL field. The HTTP request is of the following form:

POST https://example.com/endpoint HTTP/1.1
X-Mine-Signature: 4r4ClKnSeGWvTGQzMCUcEEK9uF528mvOlN/jtKMQ==
Content-type: application/json

{
  "EventId": "123456789abcdefghijklm",
  "EventType": "WebhookSlim",
  "isTest": "false",
  "ticketInfo": ...
}

The receiving endpoint is expected to return one of the following responses:

200 OK (Sync Flow)

Returning 200 indicates to MineOS that the deletion process has been completed successfully and will be marked as 'completed' in the UI.

202 Accepted (Async Flow)

Returning 202 indicates to MineOS that the deletion process has started, and the process will be marked as 'in progress' in the UI. Your endpoint can now use as much time as it wants to delete or anonymize user data. Once completed, you should use the Update custom integration status [v2] API to update the integration status. You can only call the update integration status API once; the operations is considered as completed once you call it.

Any other status code

Failing to respond with 200/202, or returning any non 2xx http status code, will cause MineOS to keep retrying the request until a valid 200/202 response is returned or the retry attempts have reached a maximum, marking the process as failed.

Examples: Handling success and failure

When using the Update custom integration status [v2] endpoint it's important to use the status field properly. In general:

Completed: The result was completed successfully, and MineOS should consider this DSR as completed, meaning no further operation/retry is necessary.
UserNotFound: The requested user (or his data) was not found. Since its a perfectly valid state this is treated the same as 'Completed'.
CannotDeleteData: The requested user and his data was found, but the system is not allowed to delete it. This is treated the same as 'Failed'.
Failed: means the result of the operation is not as intended, and the system should not consider this DSR as completed. Failed usually means an error that cannot be retried and requires user intervention.

Here are a few examples that demonstrate proper use of the status field:

Example 1: A request of type delete, but no user data/id was found.

In this example, you should use status=UserNotFound. The reason is that the DSR can (and should) be considered handled. If a user requested his data to be deleted and no data exists - that is perfectly fine.

Example 2: A request of type delete, but some user data has to be kept

In this example, user data was deleted, with the exception of some data that had to be retained due to other business/compliance requirements. As this is a perfectly acceptable way to handle deletion requests and the DSR can be considered as done, you should use status=Completed.

Example 3: A request of type delete, but the user has future reservations or an active subscription and cannot be deleted

In this example, user data should not be deleted as a business decision. The DSR cannot be honored and should not be considered as done, you should use status=CannotDeleteData.

Example 4: A request of type delete, but some user data failed to delete

In this example, user data was attempted to be deleted but some of it failed. This can happen because of a network error accessing a required endpoint, database authentication error or a number of other reasons that prevented required data from being deleted. In this example the DSR should not be considered as completed, and the user should use status=Failed.