Automatic Check-in and Check-in Monitoring

Run daily check-ins for supported relay accounts, collect credits, and save the latest execution result so you do not have to remember every site manually.

Features at a Glance

• Check-in status detection: Adding or refreshing an account automatically detects whether its site has a check-in entry point. There is no manual "check-in detection" switch.
• Custom check-in entry point: If the page is not at the standard path, enter an External Check-in Site URL under the account's Check-in Settings.
• Automatic scheduling: Uses browser background scheduling for a regular once-per-day automatic check-in and optional same-day retries for eligible failed or unconfirmed results.
• Execution result: Saves the latest result with success, failure, skip reasons, last run time, and next schedule. This is not a multi-day history log.

Requirements

1. The account has been added in Account Management and completed at least one successful refresh or detection.
2. Make sure the account has valid login credentials. With Automatic Selection, accounts without a selected method can run discovery during the daily task; check-in starts only after a usable method is confirmed. See Supported Sites and Authentication below.
3. Under Account Management → Edit Account → Check-in Settings, the Enable Daily Auto Check-in switch is visible. Only accounts with a built-in provider show it.
4. The browser must support background scheduling. Exact timing is not guaranteed when the browser is closed, the device sleeps, or background policies change.

Setup

1. Account-level Settings

• Open an account → Edit Account → Check-in Settings.
• Accounts with a built-in provider show:
  • Check-in Method: Automatic Selection re-detects as needed when no method is selected or the current method is confirmed unavailable. It selects or switches only when a suitable method can be uniquely determined. A manual choice stays fixed. If it still belongs to the current site but has no detection record, execution confirms only that method and keeps that choice whether the result matches, is unsupported, or is uncertain.
  • Enable Daily Auto Check-in: Enabled by default. When disabled, the account does not participate even if the global schedule is enabled.
  • Check-in API Path (optional): Enter it when the site changed its built-in check-in endpoint (some New API forks do). Leave it empty to use the default path; Re-detect Check-in Methods tries to read it automatically first, and a successful read lets that same detection finish on the new path. Detection preserves manually entered paths and can relearn an automatically discovered path after it stops working. Clear the field and save to restore the default path.
  • External Check-in Site URL (optional): Enter it when the page is not at the standard path. Every account can configure an external entry point.
  • Custom Recharge/Redemption Page URL (optional) and "Open the recharge page when using external check-in".
• The account form has no "check-in detection" switch. Status is read automatically during account refresh or detection.
• Automatic re-detection requires both the global and account-level automatic check-in switches. It runs with the daily task, including a daily task triggered early by opening the interface, with at least 24 hours between automatic discovery attempts for an account. Network errors, timeouts, and expired logins do not mean the method is unsupported.
• Re-detect Check-in Methods is available manually during the cooldown. It only finds methods and does not submit a check-in; discovery results in the account editor take effect when saved.

2. Global Time Window

Under Settings → Check-in & Redemption → Automatic Check-in:

Settings take effect after saving, without restarting the extension. Upgrades preserve your saved settings.

3. View Execution Status

• Open Automatic Check-in in the settings sidebar to see the latest result, the next daily schedule, and the next retry schedule when present.
• Results show eligible, executed, successful, failed, and skipped states. The bottom also shows account detection state, provider, skip reason, and latest result.
• Click Run Now to run eligible accounts once, regardless of the global automatic check-in switch. Accounts must still be enabled and meet check-in requirements. To process one account, use Quick Check-in in its menu.
• The Quick Check-in calendar icon at the top of the popup or side panel opens the check-in page and starts a manual batch.
• Failed rows can offer Retry, Manual Check-in, External Check-in, or Open Site. Manual Check-in requires you to finish the action on the site.
• "Pending confirmation" offers Verify Status only when the method can read today's status. Methods without that read offer Try Again instead of a verification action that cannot succeed. Automatic retries follow the execution and retry rules below. For methods that cannot safely repeat a claim, confirm the result on the site first.
• To report a problem, choose check-in feedback or a support request in the account menu or result row. Review the report before copying it or opening it on GitHub to submit.

4. Handle Detection and Execution States

The account's check-in configuration retains your manual method choice and custom URL. Network errors or an expired login do not trigger a method switch. Take the corresponding action based on the state:

Execution and Retry Rules

• Daily schedule: One regular check-in is scheduled each day within the configured local time window, followed by the next day's schedule. Closing the browser or putting the device to sleep may delay execution; the extension cannot make up a previous day's check-in.
• Before execution: The extension checks the method, credentials and today's status. It does not choose arbitrarily when no method applies, several candidates remain or discovery is incomplete. A method confirmed unavailable can be replaced with a unique alternative under the discovery rules. If a submitted request is pending confirmation, the result is checked before any further action; the extension does not switch methods and submit again.
• Completion: Both Success and Already Checked In Today count as complete. A newly successful check-in also refreshes account data.
• Retry conditions: When enabled, eligible failed and pending results are retried later the same day. Sign-in requirements, insufficient permissions, disabled or unsupported methods, an invalid execution environment, or missing account or credential prerequisites block automatic retries. Methods that cannot safely repeat a claim also skip automatic retries; confirm their result on the site first.
• Before retrying: Methods that can read status check today's result first and skip submission if already complete. Methods without status readback retry directly. A single execution never immediately submits twice.

Supported Sites and Authentication

The following sites have supported check-in methods. Availability still depends on account detection:

Check-in differences between Sub2API sites

Sub2API operators may add their own check-in features. Keep the account type as sub2api; availability depends on the detected method. Use the setup steps above to re-detect, save and enable automatic check-in.

AgentRouter login check-in and account login

AgentRouter checks in by signing in again. In the account editor, select login check-in under Check-in settings to reveal the separate Account login section below. The check-in section shows the configured method and links to it. Turning automatic check-in off does not hide it, because manual check-in also needs login. Selecting another check-in method hides it without clearing saved login settings.

• Username and password: choose this method and enter the website login username and password for the account. Passwords are hidden by default, stored per account, and may be included in account backups and sync. They are not API keys and do not replace API access tokens. Saving updates configuration without signing in.
• Login flow and sessions: password login opens the website’s password entry first, then fills and submits its native form. Recognized login agreement checkboxes are selected automatically; checked items stay checked, and optional items such as marketing subscriptions remain unchanged. CAPTCHA, two-factor authentication and pages requiring manual interaction use the extension’s existing assistance reminders in the same login window. API fallback is limited to cases with no identifiable native login controls before submission and no additional verification requirement. Unrecognized login screens remain open for you to operate, and uncertain submissions are not repeated. Login-based check-in requires a fresh login rather than reuse of an existing session. Allowing the extension in private windows helps separate regular-window sessions, although private windows can still share a session. An existing session is signed out automatically only in a private context with no other same-site tabs; otherwise, the extension asks you to confirm and sign out manually before continuing with the target account.
• GitHub / Linux DO: these use the corresponding identity in your browser. Adding an account preselects a method only when the site reports a single bound identity. Multiple or missing bindings require an explicit choice. The extension does not guess or switch methods after a failure.
• Third-party identity conflicts: each GitHub / Linux DO method can belong to only one account with automatic check-in enabled. Owned options are disabled for other accounts; background execution skips non-owners. This restriction does not apply to per-account passwords, but browser logins still execute sequentially.
• Change or clear: change the method under Account login, or choose Not configured to clear it. Saving a switch to third-party login removes the password. Changing the site URL, site type or account ID also clears login configuration to avoid sending credentials to the wrong account.
• Verification and results: login runs only when check-in is executed, and verifies the signed-in account. Complete CAPTCHA or two-factor verification on the website when required. A successful login counts as a successful check-in only with confirmation from the site. Uncertain login mutations are not replayed automatically. This configuration does not enable automatic reauthentication or credential renewal.

If no available method is detected for another site, use an external check-in URL, check in manually, or request check-in support.

Best Practices

• Time window: Prefer off-peak hours, such as early morning, for a higher success rate.
• Keep the browser running: A closed browser or sleeping device does not check in and cannot wake the device. A missed alarm may run late after wake-up, and the previous day is not backfilled. See the Chrome Alarms API.
• External and manual check-in: External Check-in only opens the configured page and records that it was opened today; it does not submit or verify the page. Manual Check-in opens the site's native page and requires you to complete the action there.
• Multiple devices: WebDAV and GitHub Gist sync accounts and preferences, but do not share today’s check-in state, latest results, or browser schedules. Enable automatic check-in on only one device to avoid duplicate runs.
• Notifications: Daily schedules and automatic retries send task notifications after completion, configured under Settings → General → Notifications. Manual Run Now and per-account Quick Check-in do not send scheduled-task notifications.

FAQ

Related Documentation

• Auto-detection Troubleshooting
• Auto Refresh and Real-time Data
• WebDAV Backup and Automatic Sync
• Cloudflare Helper
• Task Notifications