Working with a coding agent? Point it at earnesty.app/docs/integration/llms-full.txt — all public integration guides in one Markdown file, no key required.

Testing your integration

You test with an account of your own in your app: Earnesty enrolls it like any user, a test reward changes its real balance, and a real post from it is checked and charged like anyone’s. The introductory credits cover your testing.

Customer testing controls live on Integration, not on marketing offer screens. Reusing a ready reward type with new amounts, dates or posting rules does not require another delivery test.

1. Enroll an account of yours

Run your app’s normal enrollment for the account: sign it up, or let your backfill reach it. Then enter its ID in Integration → Check an account. The ID is your app’s own ID for the account, the productUserId your backend sends.

If the check says your app has not enrolled the ID, your backend has not yet called POST /v1/users for it with this app’s API key. If it says the ID is enrolled in another app, your backend is using that app’s key.

2. Send a test reward

Press Send test reward beside each reward type. It goes to the account you checked, and we remember that account for this connection. Each test sends one unit, then repeats exactly the same request.

Test rewards affect the account’s actual spendable balance. Apply kind: "test" through your normal balance and deduplication transaction. The account’s spendable balance must increase by exactly one unit, not zero or two. An HTTP success proves acceptance; check the balance too. Logging-only or separate-ledger handling is an explicit customization, not the default, and does not satisfy this check.

After a test reward is accepted, Send test revocation sends kind: "revocation" with revokes naming that test reward, twice under one reference. Your handler should take the unit back once, so the balance returns to where it started, and answer 2xx both times. A real revocation arrives the same way when a rewarded post is gone at its settlement check, five days after posting on X.

Confirm that your app handles each permanent reward key. Offer activation requires that mapping confirmation and a successful test of the saved production connection. Changing its credentials, endpoint or signing secret invalidates the old connection proof. Unsaved-pair tests cannot establish readiness.

The Test live reward delivery section shows a compact readiness summary and collapses when all live reward types are mapped and tested. Expand it to retest or to reach optional development testing. Tests send a direct reward without a campaign or post; response details stay collapsed. After a successful delivery, unconfirmed types ask the developer to confirm that exactly one unit arrived.

Development connection (optional) is collapsed by default. Save its endpoint, separate bearer key and signing secret, and a development account ID. A public HTTPS endpoint or tunnel is required when Earnesty is hosted. Development tests never fall back to production credentials, never establish production readiness, and never redirect actual earned-reward deliveries. They do not require posts or consume processing credits.

3. Make one real post

Before releasing to your users, post on X from the account and press Check my post on its rewards page inside your app. Preview rewards page in Integration opens the same page. This is the test that proves the disclosure, the account binding and the whole loop as your users will meet them.

The post is checked and charged like any accepted post: one processing fee, the same checks, the same cooldown and funding rules. It earns under whatever offer it matches, and its reward reaches your endpoint through the real delivery worker, signature and retries included. A post that carries an open Drop’s tag takes one of that Drop’s places. The post appears in the dashboard and in Programme operations like any other.

Use offers you are ready to run, or a short Drop you end afterwards.