ERROR_OAUTH: Application not installed is not a wrong secret or an expired session. It is the authorization server of Bitrix24 (Alaio) telling you that the client_id you are authorizing with is not installed on the account you point it at — the credentials can be perfectly valid and the error still appears. Below: the mechanics, the situations that produce it, and the order in which to check things.

What does ERROR_OAUTH: Application not installed actually mean?

The OAuth 2.0 flow starts on the account itself: the user is sent to the portal's authorization page with your client_id, and only if the portal accepts that identifier does it return the user to the application's redirect_uri with a short-lived code (valid for 30 seconds), exchanged for tokens at https://oauth.bitrix.info/oauth/token/. The documentation is explicit about the branch you hit: if the app is installed, the user returns to the redirect_uri; if it is not, the user sees an error instead.

So the check that fails is a registration check, not a credential check. Every issued token belongs to one account — identified by member_id, which stays stable even if the domain changes — and to one application installed on it.

Which scenarios produce this error?

Five recurring ones:

  • The companion Market app was never installed. Most third-party services (automation platforms, telephony, form builders) publish a small app on the Bitrix24 Market that must be installed on the account before the connector is authorized. Connecting first and installing later is the most common cause of this error.
  • The app was uninstalled, then re-authorized. Only administrators can uninstall Market apps, and the uninstall dialog offers to delete the application's settings and data. Tokens stored on the external side survive as strings but no longer refer to anything.
  • You are authorizing the wrong account. A test portal, a second company account, an account moved to another domain. The app is installed — just not there.
  • The app is a local one. Local applications are added directly to a specific Bitrix24 and live only there; they are managed in the developer resources section, not in the Market list. A local app's client_id will never authorize on another account.
  • The subscription lapsed and the app was removed. Note the difference: an expired trial or paid period is reported as PAYMENT_REQUIRED, not as ERROR_OAUTH. This error appears only once the app itself is gone.

How do I check whether the app is really installed?

Open the account you are actually connecting to and go to Market → More → Installed apps. That list is authoritative: if the app is not there, re-entering keys will not help. For a local application, look in the developer resources section of the same account instead.

Two things to confirm while you are there. First, that this is the same domain the OAuth request goes to — copy it from the browser rather than from memory. Second, that access is not restricted: an administrator can limit which users may work with an app, and a user outside that list gets user_access_error — a different error, and one that proves the app is installed.

How is this different from an expired token?

Completely. An expired access_token is routine: it lives 3600 seconds, and the API answers expired_token with HTTP 401. The app then requests a new pair with grant_type=refresh_token, and the stored refresh_token is good for 180 days — see token expired and invalid_grant for that failure mode.

ERROR_OAUTH: Application not installed cannot be refreshed away — there is nothing to refresh against, so the retry loop your integration runs on 401 will spin forever. Treat the two classes separately in code: one recovers automatically, the other needs a human to install something. NO_AUTH_FOUND is a third case — malformed or unknown credentials.

What is the check sequence?

  1. Confirm the target account domain, then look for the app in Installed apps on that exact account.
  2. If it is missing, install it from the Market as an administrator and authorize again.
  3. If it is present, verify that the client_id in your integration belongs to that app and not to another registration.
  4. If both match, check user-level access rights — it may be user_access_error instead.
  5. If the app was reinstalled at any point, discard the old tokens and run the flow from scratch. A reinstall issues a new pair; the old ones are dead.

For the wider map of REST failures, see the Bitrix24 REST API error codes reference. If the app is installed but its page will not render, that is a separate problem — an app iframe that does not load. If you are building the integration yourself, webhooks authorize differently and are not subject to this error at all.