> ## Documentation Index > Fetch the complete documentation index at: https://moengage-sdk-docs.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Delete Users in Bulk > This API can be used to delete users in MoEngage. Users cannot be retrieved once deleted. Users deleted (hard delete) using this API will be deleted after a default buffer of 24 hours. During this buffer period, the user will still be active in MoEngage and will be visible in Segments, Analytics, and Campaigns. Users can be updated in the buffer period.After the buffer elapses, the user is hard-deleted from MoEngage. If a user with the same unique identifiers as the deleted one is created in MoEngage (through APIs or imports), they will be created again in MoEngage. ### Rate Limit The rate limit is 1 user per payload per request. You can run 5000 requests per minute. ### Postman Collections We have made it easy for you to test the APIs. Click [here](https://www.postman.com/moengage-dev/api-docs/request/3182294-b591486a-58b1-4920-ad5f-db6dd5da92f1) to view it in Postman. ### FAQs * **Can you reverse a delete operation?** There are no rollback mechanisms for undoing the delete action. Once the delete request is processed, the user is deleted from MoEngage. * **Are the events of the users also deleted as well?** No, the events corresponding to a user are not specifically deleted; only the user and the user attributes are deleted when the delete API request is processed. However, once the user is deleted from MoEngage, the events corresponding to the user will not be accessible, i.e., if the event is used in a segmentation query the deleted user who had executed the event will not be added to the calculated segment or campaign. * **How do you check if a user has been deleted from MoEngage?** Navigate to `Segment` -> `Create Segment` on the MoEngage Dashboard. Type the unique identifier for the deleted user (the unique identifier could be the ID, MoEngage ID, phone number, email, or any unique identifier that you've configured). If the user has been deleted (hard delete), you will not be able to get any search results. For more information about searching users, refer to [Search User in Segmentation](https://help.moengage.com/hc/en-us/articles/206169646-Create-Segments#01G2PMG9GXFXRYJQ5JRJHC4V60). ## OpenAPI ````yaml /api/data/data.yaml post /customer/delete/bulk openapi: 3.0.3 info: title: MoEngage Data APIs version: '1.0' description: >- This is a comprehensive OpenAPI specification for MoEngage's Data APIs, including User, Event, and Device management. It's designed to power an interactive API playground on your new documentation site. servers: - url: https://api-0{dc}.moengage.com/v1 description: MoEngage Core API Server variables: dc: default: '1' description: >- The ‘dc’ in the API Endpoint URL refers to the MoEngage Data Center (DC). MoEngage hosts each customer in a different DC. You can find your DC number and replace the value of ‘dc’ in the URL by referring to the DC and API endpoint mapping [here](https://help.moengage.com/hc/en-us/articles/360057030512-Data-Centers-in-MoEngage). Your MoEngage Data Center (DC) can be 1, 2, 3, 4,5, 6. enum: - '1' - '2' - '3' - '4' - '5' - '6' security: - Authentication: [] tags: - name: User description: Operations for creating, updating, retrieving, and managing user profiles. - name: Event description: Operations for tracking user events. - name: Device description: Operations for managing user devices. - name: Tracking description: Endpoints for tracking attribution and installs. - name: Utilities description: Utility endpoints for testing connections. - name: File Imports description: Operations for managing asynchronous file imports. - name: Bulk description: Operations for importing users and events in bulk. - name: Webhooks description: Incoming webhook specifications from MoEngage. paths: /customer/delete/bulk: post: tags: - User summary: Delete Users in Bulk description: > This API can be used to delete users in MoEngage. Users cannot be retrieved once deleted. Users deleted (hard delete) using this API will be deleted after a default buffer of 24 hours. During this buffer period, the user will still be active in MoEngage and will be visible in Segments, Analytics, and Campaigns. Users can be updated in the buffer period.After the buffer elapses, the user is hard-deleted from MoEngage. If a user with the same unique identifiers as the deleted one is created in MoEngage (through APIs or imports), they will be created again in MoEngage. parameters: - name: app_id in: query required: true description: >- This is the Workspace ID of your MoEngage account that has to be passed along with the request. You can find your Workspace ID at Settings > Account > APIs > Workspace ID. schema: type: string example: VJ0GSMESHMQA3L7WV1EEK3UR - name: X-Forwarded-For in: header required: false description: >- The 'X-Forwarded-For' header is used to specify the IP address of the client that made the request. This header may be added by proxy servers or load balancers. The header value must contain the IP address of the original client that initiated the request. Multiple IP addresses may be specified in the header value, separated by commas. schema: type: string example: 203.0.113.195 requestBody: required: true content: application/json: schema: properties: identity_type: type: string enum: - customer_id - id description: >- This field specifies the identifier type. Identifier types can either be customer_id (ID field in the User Profile) or moengage_id (the MoEngageID of the user in the User Profile). Allowed values are "moengage_id", "customer_id". example: customer_id identity_value: type: string description: >- This field specifies the unique identifier that identifies the user. example: 6416d1a318r98264512c0f89 responses: '200': description: >- This response is returned when the request is processed successfully. content: application/json: schema: type: object properties: status: type: string description: >- This field contains the status of the request and specifies whether the request was successful. Supported values are success, fail example: success message: type: string description: >- This field contains information about whether the response is being processed, the user is deleted, and so on. example: Your request has been accepted and will be processed soon examples: success_response: summary: Successful request value: status: success message: Your request has been accepted and will be processed soon. '400': description: >- This response is returned when the required parameters APP KEY, user_id, etc are missing from the request or when the provided params are invalid. content: application/json: schema: type: object properties: status: type: string description: >- This field contains the status of the request and specifies whether the request was successful. Supported values are success, fail example: fail error: type: object properties: message: type: string description: >- This field contains the error message and describes the reason for the error. type: type: string description: >- The type or category of the error (e.g., Authentication Required, Invalid Params). request_id: type: string description: >- A unique identifier for the request, useful for debugging. examples: bad_request: summary: Bad Requests value: status: fail error: message: >- User doesn't exists with customer id b3XSJ7iXvqlCcrYGd5SB5m2m93eG9-9e9HPXd9GtufHvHueWm-mnuiAxUk7DGI1MKg== type: Not Found request_id: bYvNTyWb '401': description: >- This response is returned when the authorization fails due to incorrect values for the APP KEY/ HTTP Auth Header. content: application/json: schema: type: object properties: status: type: string description: >- This field contains the status of the request and specifies whether the request was successful. Supported values are success, fail example: fail error: type: object properties: message: type: string description: >- This field contains the error message and describes the reason for the error type: type: string description: >- The type or category of the error (e.g., Authentication Required, Invalid Params). request_id: type: string description: >- A unique identifier for the request, useful for debugging. examples: authorization_error: summary: Authorization Errors value: status: fail error: message: >- App Secret key mismatch. Please login to the dashboard to verify key type: Authentication required request_id: pIvbWnGT '403': description: >- This response is returned when your MoEngage account has been blocked or suspended. content: application/json: schema: type: object properties: status: type: string description: >- This field contains the status of the request and specifies whether the request was successful. Supported values are success, fail example: fail error: type: object properties: message: type: string description: >- This field contains the error message and describes the reason for the error type: type: string description: >- The type or category of the error (e.g., Authentication Required, Invalid Params). request_id: type: string description: >- A unique identifier for the request, useful for debugging. examples: appid_invalid: summary: Blocked/Suspended Accounts value: status: fail error: message: given app_id is invalid/blocked type: InvalidParams request_id: pIvbWnGT '429': description: >- This response is returned when the number of requests per minute has exceeded the rate limit. content: application/json: schema: type: object properties: title: type: string description: >- This field is present in the response in the case of 429 and 5xx errors and contains the type of error. description: type: string description: >- This field is present in the response in the case of 429 and 5xx errors and contains the error description. examples: rate_limit: summary: Rate limit breach value: status: fail title: Rate limit exceeded description: Exceeded rate limit for this url '500': description: >- This response is returned when the system runs into an unexpected error. content: application/json: schema: type: object properties: title: type: string description: >- This field is present in the response in the case of 429 and 5xx errors and contains the type of error. description: type: string description: >- This field is present in the response in the case of 429 and 5xx errors and contains the error description. examples: unknown_error: summary: Unknown errors value: status: fail title: Internal Error description: Please contact the MoEngage team. components: securitySchemes: Authentication: type: http scheme: basic description: > This authentication parameter, used for access control, must be passed along with the request. The API request will be authenticated through Basic Authentication. Basic Authentication sends a Base64-encoded string containing your username and password with every API request. It encodes a 'username:password' string in Base64 and appends the encoded string with 'Basic '. This string is included in the authorization header as shown below: `{"Authorization: Basic Base64_ENCODED_WORKSPACEID_APIKEY=="}` The username and password details can be obtained from the MoEngage Dashboard. If you're using the API for the first time, follow these steps: 1. Navigate to Settings -> Account -> APIs. 2. Copy the following details: * **Username:** Under Workspace ID (earlier app id), click the copy icon to copy the username. * **Password:** In the **API keys** section, click the copy icon in the **Data** tile to copy the API key. Use these details to authenticate the API requests. ````