jQuery compatibility

amoCRM-style widgets are written as define(['jquery'], function ($) { ... }). Bito resolves that dependency to real jQuery 4 — the full (not slim) build that ships with the admin panel. Only a handful of methods are replaced; everything else — DOM, events (namespaces included), effects, $.fn plugins, $.Deferred — behaves exactly as in stock jQuery 4.

It is reachable only as your module's 'jquery' (or '$') dependency and as the $modal handed to the settings callback. Bito never attaches it to window.$ or window.jQuery, and the admin panel itself does not use jQuery — a third-party script of yours that expects a global will not find it. Every widget on the page shares one $ instance: a plugin you add to $.fn is visible to other widgets too, so give it a unique name.

What is replaced

Method	What happens
$.ajax, $.get, $.post	Go through the admin panel's HTTP client — see below.
$.trim	Removed in jQuery 4, restored as String(value ?? '').trim().
$.isArray	Removed in jQuery 4, restored as Array.isArray.
$.isFunction	Removed in jQuery 4, restored as typeof value === 'function'.
$.parseJSON	Removed in jQuery 4, restored as plain JSON.parse — an empty string throws.

Those seven only. Other helpers jQuery 4 removed — for example $.type, $.now, $.isNumeric, $.isWindow, $.camelCase, .andSelf(), .size() — are not restored: replace them with native equivalents in older code.

$.ajax goes through the app's HTTP client

$.ajax, $.get and $.post do not use jQuery's XHR; they run on the same HTTP client the admin panel uses. So a request carries the signed-in user's auth, language, time zone and idempotency key — your widget needs no credentials of its own. Consequences:

• The HTTP method collapses. Only GET stays GET; any other type/method, including PUT, DELETE and PATCH, is sent as POST — matching the admin API, which uses POST even for reads.
• The URL is taken as given. Unlike bito.ajax, nothing prefixes it for you.
• Supported options: url, type/method, data, headers, timeout, success, error, complete. dataType and every other jQuery setting are ignored, and $.ajaxSetup defaults are not applied.
• The response envelope is unwrapped. success and done receive the data part of Bito's response, not the whole { code, data, ... } envelope.
• jQuery helpers built on these three ($.getJSON, .load()) take the same path. Because dataType is ignored, $.getScript does not execute the script.

The return value is a jQuery Deferred promise (done/fail/always/then) with jqXHR-style fields added:

Field	Value
status	200 on success; the HTTP status from Bito's error on failure; 0 on a network failure
statusText	"OK" on success, the error message on failure
responseJSON	The unwrapped response (success) or Bito's error envelope (failure)
responseText	The same, as a JSON string
readyState	1 until the request settles, then 4
abort()	A no-op. The request cannot be cancelled.
getResponseHeader(), getAllResponseHeaders()	Always null / "" — response headers are not exposed

success(data, 'success', jqXHR), error(jqXHR, 'error', err) and complete(jqXHR, status) are called in jQuery's order, and done/fail fire synchronously, as in jQuery.

$.ajax({
  url: '/back-api/admin/customer/get-paging',
  data: { page: 1, limit: 20 },
  success: function (data) { /* data is the envelope's `data` */ },
  error: function (jqXHR) {
    if (jqXHR.status === 403) { /* ... */ }
  },
})

WARNING

If the admin API answers 401, the admin panel signs the user out — that applies to your widget's requests too.

To call Bito's admin API, prefer bito.ajax — it adds the prefix for you.