Endpoint responsible for restoring a customer previously removed from the Asaas account.

Restoration allows a customer record to become available again for use in the integration’s operational flows, such as consultation, cadastral update, creation of charges, subscriptions, and other resources that depend on an active customer.

This endpoint should be used when the customer removal was improper or when your application needs to reactivate a previously removed record without creating a new duplicate customer.

When to use this endpoint

Use this endpoint when your integration needs to:

• reverse the improper removal of a customer;
• recover a record removed due to an operational error;
• reactivate a customer that still needs to be used in new flows;
• correct an incorrect synchronization between your database and Asaas;
• avoid creating a new duplicate customer;
• keep the same customer identifier in integrations that already stored the Asaas id.

This endpoint is useful in scenarios where the customer was removed, but still needs to remain related to your platform’s operation.

When not to use

Do not use this endpoint to:

• create a new customer;
• restore charges, subscriptions, or other removed resources;
• recover a customer whose identifier is not known;
• replace the customer creation flow;
• reactivate records that do not belong to the authenticated account;
• correct customer cadastral data.

If the objective is to change cadastral information of an active customer, use the customer update endpoint.

Request parameter

This endpoint uses only the customer identifier in the request path.

The id must correspond to a customer previously created in Asaas, normally in the format:

cus_000005401844

This endpoint does not use body parameters.

Prerequisites

Before requesting restoration, check whether:

• the customer was previously created in Asaas;
• the customer was previously removed;
• your application has the customer id identifier;
• the API key used belongs to the account where the customer was created;
• the customer was not replaced by another record in your internal database;
• your application is prepared to synchronize the customer status again after restoration.

Recommended flow

In a typical integration, the customer restoration flow should follow the steps below:

Identify the removed customer in the internal database
↓
Validate the customer id in Asaas
↓
Request restoration
↓
Validate the API response
↓
Consult the restored customer
↓
Update the customer status in the internal database
↓
Resume flows that depend on the active customer

After restoring the customer, it is recommended to perform a new consultation to confirm the current state of the record before proceeding with dependent operations, such as creating charges or subscriptions.

Request example

curl --request POST \
  --url https://api-sandbox.asaas.com/v3/customers/cus_000005401844/restore \
  --header 'accept: application/json' \
  --header 'access_token: $ASAAS_API_KEY'

Response example

After restoration, the API returns the restored customer data.

{
  "object": "customer",
  "id": "cus_000005401844",
  "dateCreated": "2026-06-30",
  "name": "Example Customer",
  "email": "[email protected]",
  "cpfCnpj": "12345678909",
  "phone": "1130000000",
  "mobilePhone": "11990000000",
  "deleted": false
}

Restoration behavior

When restoring a removed customer:

• the record becomes available again for consultation and use in the Asaas account;
• the same customer id identifier is maintained;
• the customer can be used again in new flows that require an active customer;
• the operation does not create a new customer;
• the operation does not automatically change the customer’s cadastral data;
• the operation should not be treated as the creation of a new record;
• your application must update the customer’s status in the internal database after the successful call.

Restoration should be understood as a reversal of the customer record removal, and not as a complete recreation.

Relationship with other resources

Customers can be related to other API resources, such as:

• charges;
• subscriptions;
• notifications;
• invoices;
• installment charges;
• internal settings of your application.

Customer restoration should not be used as a guarantee that all linked flows will automatically be ready for use without validation.

After restoring the customer, it is recommended to consult the related resources that your application uses to confirm whether the flow can continue normally.

Examples:

• if the customer will be used to create a new charge, consult the restored customer before creation;
• if the customer was associated with a subscription, validate the subscription status;
• if there were previous charges, consult the status of those charges before updating reconciliation;
• if your application removed or deactivated the customer internally, synchronize the local database again.

Idempotency and repeated calls

Do not treat this endpoint as an idempotent operation without validating the API response.

If restoration is requested more than once for the same customer, the behavior may vary according to the current state of the record.

Possible scenarios:

Therefore, after a successful call, update your internal database to avoid unnecessary new attempts.

Important business rules

Before implementing this endpoint, consider the following rules:

• only previously removed customers can be restored;
• the id provided must belong to a customer of the authenticated account;
• the endpoint does not create new customers;
• the endpoint does not restore charges, subscriptions, or other resources removed separately;
• the endpoint does not update cadastral data;
• restoration keeps the customer’s original identifier;
• the application must validate whether the restored customer is fit for the next flow;
• the public endpoint documentation does not indicate a time limit for restoring removed customers.

Common errors

Some common errors when using this endpoint include:

Best practices

When implementing restoration of removed customers, it is recommended to:

• store the customer id returned by Asaas at the time of creation;
• avoid creating a new customer before trying to restore the removed record;
• register logs of who requested the restoration and when it occurred;
• consult the customer after restoration to confirm the updated state;
• synchronize your application’s internal database after a successful call;
• validate related resources before resuming automatic processes;
• handle 400, 401, and 404 errors clearly for the operator or internal user;
• avoid automatic retries without checking the customer’s current state;
• test the flow in Sandbox before making the feature available in Production.

Operational impacts

Restoring a customer can impact internal integration flows.

Some possible impacts are:

• reactivation of the customer in internal records;
• resumption of the possibility to create charges for the customer;
• need to synchronize status between Asaas and the external system;
• risk of duplication if the application creates a new customer instead of restoring the existing one;
• divergence in reports if the customer is removed in one system and active in another;
• need to validate charges, subscriptions, or related records after restoration.

Therefore, treat restoration as a sensitive administrative operation and maintain internal traceability.

Sandbox precautions

This endpoint can be tested in Sandbox.

It is recommended to validate the following scenarios:

• create a customer;
• remove the customer;
• restore the customer;
• consult the customer after restoration;
• try to restore the same customer again;
• try to restore a nonexistent ID;
• validate how your application updates the internal database in each response.

These tests help define the expected behavior before operating in Production.

Related content

See also:

• Create new customer;
• List customers;
• Retrieve a single customer;
• Update existing customer;
• Remove customer;
• Create new charge;
• Create subscription;
• What can be tested in Sandbox.