A rejected KocakZ key does not automatically mean the key is wrong. The same visible failure can begin with an expired credential, an incomplete copy, a device limit, a full session allowance, a revoked key, or a temporary network problem. The fastest fix is to identify which stage rejected the request before changing anything.

This guide gives you a repeatable diagnostic order. It starts with checks that cannot damage your access, then narrows the problem using the exact message and account state. If you have not completed a claim yet, begin with How to Claim Your First KocakZ Key.

First, preserve the evidence

Before refreshing, replacing code, or opening another claim, copy the non-secret error text. Note the approximate time and which action produced it. A message shown while claiming a key belongs to a different part of the system from one shown after the loader starts.

Do not share the complete key, loader snippet, session token, Discord token, cookie, or password. A loader snippet may contain the key even when the separate key field is hidden. Redact both before posting a screenshot.

A useful starting note looks like this:

At about 20:15 WIB, the loader rejected my existing free key on the same device I used earlier. The key page shows that it has not expired. The message says the active session limit was reached.

That note identifies time, tier, device context, expiry state, and the actual limit without revealing the credential.

Identify where the failure happened

KocakZ has several connected stages. Find the last one that worked.

Failure locationWhat it usually concernsWhat it does not prove
Discord sign-inOAuth account or callback configurationThat the key is invalid
Server membershipThe connected account is not confirmed in the serverThat Discord login failed
TurnstileHuman-verification loading or validationThat the blog checkpoint is broken
Blog checkpointFlow ownership, expiry, timer, or blocker gateThat a generated key was rejected
Completed flow pageAccount ownership or flow retentionThat the loader used the copied value
Key check or loader startKey validity, expiry, revocation, HWID, or sessionsThat a new claim is required
Heartbeat after launchSession credential, expiry, revocation, or connectivityThat initial key generation failed

This separation matters because generating another flow cannot repair a loader network error, and changing an HWID cannot repair a Discord account mismatch.

Check 1: copy the original value again

Return to the completed flow or use Get Key with the same Discord account. If the account already has a valid key, KocakZ returns that stored key rather than creating a duplicate.

Use the Copy Key control. If you are copying a loader, replace the whole previous snippet rather than selecting only the part that looks different. Manual selection can add spaces, omit a character, or include Markdown fences.

Check for these common copy problems:

  • A leading or trailing space.
  • Quotation marks added around the key.
  • Three-backtick code fences copied from Discord.
  • Part of an older loader left before or after the new snippet.
  • A line break inserted inside the key.
  • A key copied from a screenshot or formatted message instead of the source control.

Do not edit a key to make it resemble another value. Keys are generated credentials; changing one character creates a different, invalid string.

Check 2: verify the Discord account

The key belongs to the Discord account used during the claim. If you use several Discord accounts, check which one the browser connected. A key retrieved with another account is not a replacement for the original account's access.

Use Get Key while signed into the intended account. If it returns a different flow or asks for server membership, stop and confirm the account before continuing. Joining the KocakZ server with account A does not satisfy a flow owned by account B.

Premium status is also associated with the account. A payment message must identify the intended Discord user ID in one unambiguous Discord: yourID line. If you expected premium but connected another account, the limits and checkpoint path may appear different from what you expected.

For a complete comparison of tier behavior, see Understanding Free and Premium KocakZ Access.

Check 3: read the expiry

A free key lasts 24 hours from issuance. Premium access follows the paid entitlement expiry. Retrieving the same valid key does not refresh either period.

Compare the displayed expiry with the current time. If another device shows the date, account for its time-zone display. The important question is whether the server considers the access active now.

If a free key has expired, start a new claim and complete the current free flow. Do not reopen an old completed flow: completion is single-use and does not become a fresh claim when its key expires.

If the key has not expired, do not assume a new claim is the next step. Continue through the checks below so you preserve the actual failure condition.

Check 4: distinguish revocation from expiration

Expiration is the normal end of a key's validity period. Revocation is an administrative state that explicitly prevents use. They are not interchangeable.

A revoked key is not repaired by repeatedly claiming or paying. Revocation is designed to survive those ordinary actions until an administrator makes a deliberate change. If the error indicates revocation, contact support with your Discord account context and the redacted message.

Do not ask someone else for their key as a workaround. It exposes their credential and can consume their device or session allowance without resolving the status of your account.

Check 5: understand HWID errors

An HWID is the submitted when the loader starts an authenticated session. Generating a key on the website does not bind an HWID. The first accepted loader run creates the binding.

Free access permits one HWID. Premium permits up to five. A browser, Discord login, and claim flow are not HWIDs. The fallback used by some executors may differ when a native hardware function is unavailable, so changing executor behavior can affect the identifier presented to the server.

If the message says the HWID limit is reached:

  1. Confirm whether the key has been used on another device.
  2. Confirm whether the current executor previously supplied a different identifier.
  3. Stop creating new claims; the current valid key remains the account key.
  4. Ask the administrator to inspect or reset bindings when the change is legitimate.

An HWID reset is an administrative action and can terminate related sessions. Describe why the current binding is no longer usable instead of asking for repeated resets without context.

Check 6: investigate session limits

A session represents an active script run. Free access allows up to five active sessions; premium allows up to 50. These limits are separate from the number of HWIDs.

The custom loader sends a heartbeat every 20 minutes. A session becomes stale after 45 minutes without a valid heartbeat. This gap avoids immediately discarding a session during a brief connection problem, but it also means closing a local window may not instantly free a server slot in every failure case.

When the session limit is reached:

  • Close runs you no longer need.
  • Avoid launching more copies while investigating.
  • Give stale-session handling time to recognize abandoned runs.
  • Use the dashboard or ask the administrator to inspect sessions if the count remains unexpected.
  • Record whether the limit changes after one stale window rather than retrying continuously.

A new flow does not erase sessions attached to a still-valid account key. Solve the session state instead of multiplying claims.

Check 7: separate startup from heartbeat failure

A successful loader start means the server accepted the key, HWID, and available session slot at that moment. The game script then receives an access context, while the loader owns heartbeat checks.

A later heartbeat rejection can happen because the key expired, was revoked, the session credential is no longer accepted, or the server could not be reached. The cooperative access context should stop protected work when the heartbeat is rejected or unreachable.

If startup succeeds but the session stops later, note how long it ran and the last visible message. Replacing the key before checking its expiry can hide whether the real problem was connectivity or a normal expiry during the run.

Client-side checks are not an absolute security boundary. The server validates credentials and limits, while the loader and game script cooperate with cleanup. Modifying local Lua does not grant valid server access.

Check 8: test connectivity without changing identity

A temporary failure reaching KocakZ, MongoDB, or Discord can produce a closed or unavailable result. Keep the same account, key, and device while checking connectivity; changing all three at once destroys the comparison.

Try one controlled retry after confirming the website itself loads. If the public site loads but the authenticated request repeatedly fails, keep the approximate time and endpoint stage for support. Do not paste raw request headers or logs publicly because they may contain tokens.

If Discord is temporarily unavailable during a membership check, the site intentionally blocks progression because it cannot confirm the requirement. Waiting and retrying the same flow is more useful than creating many new flows.

A decision tree for rejected keys

Follow this order from top to bottom:

  1. Was a key ever displayed? If no, troubleshoot the claim stage rather than the loader.
  2. Was the key copied again from the official result? If no, recopy it without formatting.
  3. Does the Discord account match the owner? If no, reconnect the correct account.
  4. Is the key expired? If yes, complete a new claim when appropriate.
  5. Does the error say revoked? If yes, contact support; repeated claims are not a fix.
  6. Does it name an HWID limit? If yes, investigate device bindings.
  7. Does it name a session limit? If yes, close or clear legitimate old sessions and allow stale cleanup.
  8. Did startup work before a heartbeat failed? If yes, investigate expiry, revocation, session validity, and connectivity at that later time.
  9. Is the error only a generic network failure? Retry once without changing the other variables, then report the repeated result.

The counter-intuitive part is that generating another key is rarely the first useful action. KocakZ intentionally reuses a valid account key, so diagnosis usually depends on the existing key's state.

Build a minimal reproducible report

A good support report answers six questions:

  1. What action did you take?
  2. Which stage displayed the error?
  3. What was the exact non-secret message?
  4. When did it happen?
  5. What tier and expiry did the account page show?
  6. Did one controlled retry produce the same result?

Use a structure like this:

Action: Started the loader with my stored key
Stage: Session creation
Time: 20:15 WIB
Tier/expiry: Free, expiry still in the future
Message: [redacted non-secret error]
Retry: Same result once on the same device
Already checked: Copied key again; confirmed Discord account

Do not attach the key itself. Support can search by the Discord account and inspect server-side state without receiving your credential in a public channel.

What not to do

Avoid these responses because they remove evidence or create new confusion:

  • Opening many claim flows simultaneously.
  • Editing the key by hand.
  • Sharing someone else's credential.
  • Posting full loader code containing your key.
  • Switching accounts, devices, networks, and executors in one test.
  • Repeatedly launching after a session-limit message.
  • Assuming every rejection means the website needs a new key.
  • Treating a client-side bypass as valid server authorization.

One controlled change at a time produces a useful before-and-after result. If copying the original key fixes the issue, you have identified a formatting problem. If the same error remains, move to the next relevant check rather than repeating the same action.

Choose the branch of the troubleshooting process that matches your error and make one controlled attempt. Write down whether the wording changed, the failure moved to a different stage, or the result stayed exactly the same. That distinction is useful even when the attempt does not fix the problem.

If you still cannot isolate the cause, turn those observations into a useful support request. Include the failed stage and the checks you completed, with credentials removed, so the next person can investigate without asking you to repeat every step.