Troubleshooting

Diagnose installation, authentication, issuance, approval, sending and status problems without creating duplicate rewards.

Start with the reward ID, campaign ID, request ID, environment, and last known state. Preserve the original instruction and key. Do not create a new allocation to test whether an uncertain one succeeded.

The SDK package cannot be installed#

Confirm the reviewed package source and version supplied for your integration. The documentation package name does not establish that a public registry release exists. Use the supplied tarball or approved registry configuration; do not install a similarly named third-party package.

See Install.

Requests return 401 or 403#

Check the server environment, API origin, key validity, and required campaign/operation access. A dashboard login is not a server API key, and a key for another environment is not interchangeable.

Do not broaden every key to full access to make a failing request work. See Authentication.

Issuance timed out#

The server may have accepted the reward. Retry the identical persisted instruction with the same key, or retrieve the known reward. If the ID is missing, list by campaign and event ID and compare event type, wallet, and amount.

Do not recompute the amount or create a new key. See Idempotency.

I received DUPLICATE_EVENT#

A reward already exists for the campaign/event-type/event-ID tuple. Read existingRewardId when provided and compare it with the original expected instruction.

An earlier cancellation does not clear the tuple. A deliberately corrected reward requires a new audited business identity, not an accidental retry workaround.

The reward is accepted but not queued#

Acceptance reserves capacity; it does not put the grant in front of your operator. Read recipient.verificationStatus: not_required means the campaign does not ask recipients to verify and the grant queued at once; an unverified recipient has not yet signed the verification message on the campaign's verification page, an expired one must renew it, and a blocked one is outside the campaign's location policy. A verified recipient's grant waits only for room in the next draft campaign, or because that wallet already has a transfer in the open draft.

Send the recipient to recipient.verificationUrl rather than issuing a second reward to a different wallet. See Recipients.

The reward is queued but not approved#

The grant is in the open draft campaign and your operator has not approved it yet. Approval is a human action in the dashboard; nothing in the API hurries it. Check with your operator whether the draft is waiting on a quote issue, on other recipients' verification, or on their wallet's balance and gas.

A pause on the campaign does not clear a draft; it stops new acceptance. See Approval and sending.

The reward is approved but not sent#

Each transfer needs the operator's wallet, one at a time. Check, in the dashboard: whether the Slices fee transfer has confirmed (recipient transfers wait for it); whether another transfer from that wallet is still unresolved (the wallet lock); whether the preflight refused the transfer, and why (statusReason on a failed reward, or the prepare message in the dashboard); and whether the recipient's verification expired after approval.

A reward that stays approved is waiting on the operator or on a preflight fix, not on Slices. Do not issue a replacement.

The transfer was sent but the reward is not delivered#

The per-minute job verifies the receipt: the sender, the recipient, the token, the exact amount, the Transfer log, and the required confirmations. deliveryEvidence shows the transaction it is watching, confirmations how far it has got, and checkedAt when it last looked. A transfer that the wallet replaced, or that the browser could not report, is resolved from the chain by the same job.

An RPC outage delays verification; it does not change the reward's status. Do not substitute a wallet's success message, a current balance, or a block explorer's view for the verified receipt. If the transaction reverted, the reward becomes failed once the chain has finalized past it, and the operator can retry.

Cancellation returns INVALID_STATE#

The reward is already approved, sent, delivered, or failed, and the API cannot cancel it. Cancellation does not become available again because a transfer is slow or an attempt failed. Coordinate with the operator: they can retry a failed transfer or close the draft campaign, which cancels its unsent transfers from their side. Do not release its capacity or issue a replacement automatically.

Polling returns errors or stale data#

Back off, respect Retry-After, and preserve the last known record with a freshness warning. Do not render zero rewards as a successful response to an outage.

Escalating an issue#

Send the request ID, relevant reward, draft campaign and campaign IDs, environment, timestamps, transaction hashes, and sanitized observations through the support process provided at onboarding. Never send API secrets, seed phrases, private keys, or unredacted personal information.

Related: Errors, Reward states, and Going live.