Testing your integration
Prove request handling and recovery locally before moving real tokens.
Test the API contract and your own business-event handling before enabling a funded campaign. A passing mock integration does not prove that an operator approved anything, that a wallet sent a transfer, or that a receipt was verified.
Start with isolated fixtures#
Use the supplied local profile, test keys, and synthetic recipients. The example TST asset and chain 31337 are not production configuration. Local fixtures must be visibly identified as fixtures.
Confirm that your application can install the SDK as a standalone package, read the approved test campaign, issue one allocation, and persist the returned reward ID.
Required partner tests#
| Scenario | Expected behavior |
|---|---|
| Valid exact allocation | One reward ID and one durable instruction. |
| Same key and identical request | Same reward ID; no new capacity consumption. |
| Same key and changed amount or wallet | IDEMPOTENCY_CONFLICT. |
| Same event under a fresh key | DUPLICATE_EVENT; no second grant. |
| Client timeout after server acceptance | Replay recovers the original reward. |
| Zero, negative, decimal, exponent, or numeric amount | Rejected without an accepted grant. |
| Amount larger than JavaScript's safe integer | Preserved exactly as a string. |
| Two requests competing for remaining capacity | Authorized cap is not exceeded. |
| Wrong project key or reward ID | No cross-project record exposure. |
| Pause or disabled issuance | New writes are rejected; authorized reads still work. |
| Eligible cancellation | Capacity restored once; event remains deduplicated. |
| Cancellation after approval | INVALID_STATE; no silent release of capacity. |
| Repeated business-event delivery | Your own outbox resends the original instruction. |
| RPC outage | A visible error and an unchanged status, not fabricated zero rewards or delivery. |
Also verify that your application does not expose the Slices key to browsers, mobile clients, logs, or analytics.
Check the UI interpretation#
Use distinct records for accepted (with verified and unverified recipients), queued, approved, sent, delivered, failed, and cancelled rewards. Confirm that your UI does not label API acceptance as a transfer, or a sent transfer as a confirmed one.
Record original amount strings and display asset decimals accurately. Show the chain evidence's checkedAt separately from local record updates.
Test packaged SDK behavior#
Install the actual SDK tarball or approved registry version in the partner application, not a monorepo symlink that hides missing files. Compile the real imports, exercise each method you use, and verify error handling.
Test cancellation of both an in-flight request and retry backoff. Remember that stopping client-side waiting does not undo a server commit.
Operator readiness is a different gate#
Before a real canary, the operator must verify the exact chain/token profile, their sending wallet and its balance, the fee treatment, the recipient verification path, and the receipt verification's confirmation requirements.
A real successful token transfer alone is not evidence that the full path from acceptance to a verified receipt works. A synthetic receipt must never be submitted as production evidence.
Run a small-value canary#
After the operator and security checks pass, an authorized human enables a restricted canary. Use ordinary issuance, let the recipient verify, approve the draft in the dashboard, send from the operator's wallet, and watch the job verify the receipt for the intended net amounts.
The result is complete only when the verified receipt supports the delivered status and your application reports it correctly. Leave slow or unresolved stages pending rather than assigning a successful state to finish a test session.
Next: Going live. For diagnosing failures, see Troubleshooting.