Correct a vote listing that uses the wrong token or RSA key

NuVotifier’s legacy RSA credentials and newer protocol tokens are different. Supplying a token where a listing expects a public key can fail even when the receiver port is reachable. Verify the listing’s supported protocol before replacing any credentials.

Before you change settings

Identify the exact public receiver and save its configuration privately. Record the listing, configured hostname, assigned port and selected protocol. Never paste an entire listener configuration into a public ticket: it can contain secrets for other routes.

Follow the request through the plugin

  1. Check the listing’s supported Votifier version and its credential field. Legacy RSA setup uses the receiver’s public key; the matching private key remains on the server.
  2. For a token-based integration, select the token intended for that public receiver. Do not substitute a backend forwarding token simply because both are short strings.
  3. Confirm the listing connects to the real public address and allocated listener port. A wildcard bind address such as 0.0.0.0 is not a destination to enter on the listing website.
  4. Save the corrected listing details and send one listing-generated test. Compare its timestamp with NuVotifier logs, then follow the accepted event through the reward listener.

Confirm the intended result

The receiver should accept the external event and the intended player should receive the configured reward once. Check a second independently configured listing without overwriting its credentials; different integrations can use different supported methods.

If the test fails

If no connection appears, investigate endpoint reachability before rotating keys. If a connection is rejected, inspect protocol and credential mismatch. A successful local reward command does not authenticate a remote listing or test its network route.

Restore the previous listing entry if you changed the wrong receiver. If a token or private key was exposed, coordinate replacement of that credential and its dependent integrations. Keep unrelated credentials and player vote history intact.


Revision #1
Created 2026-11-09 16:36:27 UTC by CloudExa Hosting Admin
Updated 2026-11-09 16:36:27 UTC by CloudExa Hosting Admin