# Ouath return unknown error

**URL:** <https://forum.wixstudio.com/t/ouath-return-unknown-error/78323>\
**Category:** Ask the community\
**Tags:** api, code, question\
**Created:** [May 26, 2026, 12:46pm UTC](https://forum.wixstudio.com/t/ouath-return-unknown-error/78323 "2026-05-26T12:46:28Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![user1916](https://sea1.discourse-cdn.com/wix/user_avatar/forum.wixstudio.com/user1916/32/90339_2.png) [@user1916](https://forum.wixstudio.com/u/user1916)\
**Post date:** [May 26, 2026, 12:46pm UTC](https://forum.wixstudio.com/t/ouath-return-unknown-error/78323/1 "2026-05-26T12:46:28Z")

</div>

Hi Wix Support Team,

I’m faced with an issue with the Wix API and would appreciate your help understanding the expected behavior.

**Working in**  
Wix API

**Site link**

> **[Create Access Token | API Reference](https://dev.wix.com/docs/api-reference/app-management/oauth-2/create-access-token)**
>
> Creates an access token. Important: Authentication methods differ depending on whether you're building a Wix app or a Wix Headless project.

**What I’m trying to do**  
When a site is moved to trash or deleted, any API request (including OAuth token requests) now returns:

```json
{
  "error": "unknown_error"
}

```

HTTP Status: 400 Bad Request

 ![image](https://us1.discourse-cdn.com/wix/original/3X/c/7/c7567b4883000372fef8b937e7bac80a23a830d6.png)

**Previous behavior:**  
A few months ago, the same scenario returned a clear and descriptive error:

- `"The requested meta-site was not found"`
- or error code: `ERROR_SITE_NOT_FOUND_CODE`

This allowed us to reliably detect when a site had been trashed or deleted.

**Current behavior:**  
The generic `unknown_error` makes it impossible to distinguish between:

1. A site that has been moved to trash or permanently deleted
2. A real unexpected server-side error

**My question:**  
Could you clarify how we are supposed to detect that a site has been moved to trash or deleted?

- Is `unknown_error` now the intended response for this case?
- Was the previous `SITE_NOT_FOUND` error removed intentionally?
- Is there a recommended approach — such as a specific error code, a webhook, or a status field in the Site object — to handle this scenario reliably?

Thank you for your time!