How the connection works
KRYGA uses standard WordPress Application Passwords and the WooCommerce REST API over HTTPS. The user approves access inside their own WordPress website, which creates a separate, revocable password for the app. The main WordPress password is never sent to KRYGA.
Both standard REST URL forms are supported: /wp-json/… and /?rest_route=/…. This helps stores whose permalink rules or security layer incorrectly blocks only one URL form.
Baseline requirements
- A public HTTPS website with a valid certificate and correct WordPress site URL.
- WordPress 5.6 or later with Application Passwords available.
- Active WooCommerce with the
wc/v3namespace in the REST API. - A WordPress Administrator, Shop manager, or compatible custom role with
manage_woocommerce. - The REST API accepts the
Authorizationheader and GET, POST, PUT, and DELETE methods. - The website can send outbound HTTPS requests to
woo.kryga.com.uafor webhooks.
Quick checks without passwords
Open these addresses in a private browser window:
https://example.com/wp-json/https://example.com/?rest_route=/
At least one must return WordPress JSON rather than a sign-in page, CAPTCHA, redirect, maintenance page, or firewall block. The response should include the wc/v3 namespace and authentication → application-passwords. An unauthenticated protected endpoint should return a normal WordPress 401/403 JSON response, not a WAF page.
Application Passwords are unavailable
Open Users → Profile → Application Passwords. If the section is missing, check HTTPS, the WordPress version, Wordfence and other security or hardening plugins, MU plugins, the theme, and custom code. They may use wp_is_application_passwords_available or wp_is_application_passwords_available_for_user.
In Wordfence, blocking of Application Passwords must be disabled. Do not turn off the whole firewall: enable only the required standard WordPress mechanism, then retry from KRYGA.
Access was created but KRYGA did not connect
If a KRYGA entry appears in the WordPress profile, browser approval has completed. A later error usually means the firewall, host, or web server blocks the authenticated REST check, strips the Authorization header, or returns a challenge instead of JSON. It does not necessarily mean the user has the wrong role.
Check blocking logs at the exact attempt time. For diagnosis, create a separate temporary Application Password, test wp/v2/users/me?context=edit over HTTPS, and revoke it immediately. Never send that password in email, chat, screenshots, or support tickets.
The Authorization header is stripped
Application Passwords use HTTP Basic Authorization. A reverse proxy, CDN, Apache, Nginx, LiteSpeed, or FastCGI must forward the Authorization header to PHP. If the public REST API works but every valid Application Password returns rest_not_logged_in, inspect this header path.
Never place the main WordPress password in a URL or enable a legacy Basic Auth plugin in production. Use only a separate Application Password over HTTPS.
Wordfence, WAF, CDN, and hosting
Review Wordfence Live Traffic/Blocking, ModSecurity, Cloudflare Security Events, country/IP blocking, Bot Fight, rate limits, hosting scanners, and User-Agent rules. Common failures block /wp-json/, the rest_route parameter, PUT/DELETE methods, or requests carrying Authorization.
Create a narrow exception for the REST API and the exact blocking rule. Do not create a global bypass or disable 2FA. If source restriction is required, KRYGA requests originate from 173.242.50.78 with User-Agent KRYGA-Store/2.0; a User-Agent alone is not trustworthy and can be spoofed.
Custom sign-in address
If standard /wp-admin/ is hidden, expand “Different sign-in address” in KRYGA and enter only a path on the same domain, such as /controlhub/. Do not enter query parameters, another domain, or a third-party SSO URL.
The custom-login plugin must preserve redirect_to and return the user to the standard Application Password approval screen. If it always opens the Dashboard, add an exception for wp-admin/authorize-application.php.
Site address and redirects
Enter the canonical HTTPS store address. Redirects between HTTP/HTTPS, www/non-www, or another domain must end at the same trusted WordPress address. KRYGA does not carry authorization across different origins, preventing credentials from being sent to another website.
Behind a reverse proxy, WordPress must detect HTTPS correctly, and home and siteurl must match the public address. Fix redirect loops, approval-page 404s, or forced Dashboard redirects before retrying.
WooCommerce role and permissions
Signing in to wp-admin does not itself guarantee WooCommerce API access. Confirm that the user still has manage_woocommerce and can read WooCommerce settings, products, orders, and webhooks. Standard Administrator and Shop manager roles normally have these capabilities; custom roles must be checked by capability rather than label.
Deleting the user, changing their role, or revoking the Application Password ends their KRYGA access. Reconnect with a current authorized account to restore it.
WooCommerce REST API
Confirm that WooCommerce is active, current, and registers wc/v3. A security plugin must not allow only WordPress endpoints while blocking wc/v3/settings, wc/v3/orders, wc/v3/products, or wc/v3/webhooks. CDN caches must not cache authenticated REST responses.
If GET works but changes fail, inspect PUT/POST/DELETE blocking, body limits, ModSecurity rules, and endpoint permissions. Do not test by changing a live product price or order; use staging or a dedicated test record.
Webhooks and live updates
KRYGA creates one shared set of its own WooCommerce webhooks per store, even with multiple connected users. Do not create or duplicate them manually. In WooCommerce → Settings → Advanced → Webhooks, they should be active and use a delivery URL on woo.kryga.com.ua.
Check outbound HTTPS, DNS, WP-Cron/Action Scheduler, and WooCommerce delivery logs. Delivery responses such as 401/403/404/5xx, a disabled webhook, or a stalled queue mean changes cannot arrive immediately. Delete only confirmed KRYGA webhooks; leave other integrations untouched.
Load and initial synchronization
The first synchronization reads products, orders, customers, reviews, and coupons in batches. On a large or constrained host, load may temporarily rise. Run it during a quieter period, watch CPU, RAM, PHP workers, database load, 429/503 responses, and logs, and pause it in KRYGA when needed.
Do not apply one aggressive global rate limit to the entire REST API. Give authenticated API requests controlled capacity; KRYGA limits concurrency and retries. After the first download, ordinary changes arrive as events, without minute-by-minute polling.
What common symptoms mean
- “Application access is disabled” — WordPress did not advertise Application Passwords: check HTTPS, filters, and security plugins.
- KRYGA access exists but verification did not finish — REST authentication is blocked or the Authorization header was removed.
- “No management permission” — authentication succeeded but required WooCommerce capabilities are missing.
- 404 after sign-in — the custom login path or security plugin did not preserve the approval redirect.
- Website unavailable / 5xx — timeout, exhausted PHP workers, plugin failure, WAF challenge, or temporary outage.
- Initial data exists but new changes do not arrive — inspect KRYGA webhook status and delivery logs.
Safe diagnostic sequence
- Create a backup or reproduce the issue on staging.
- Check canonical HTTPS and both public REST URL forms.
- Check Application Passwords and a dedicated test user’s permissions.
- Review WAF/security logs at the exact attempt time.
- Add a narrow exception without disabling the whole security layer.
- Verify the Authorization header and WooCommerce endpoints.
- Retry the connection once and inspect webhooks.
For support, send the store address, WordPress/WooCommerce/PHP versions, security plugin names, exact error time and text, and HTTP status without secrets or customer data. Never send the main password, Application Password, FTP/SSH keys, or a full database dump.