> For the complete documentation index, see [llms.txt](https://refkit.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://refkit.gitbook.io/docs/integrate-refkit/ai-coding-agent.md).

# Set up with a coding agent

In the dashboard, open **App > Integration > Coding agents**, copy the generated prompt, and paste it into Cursor, Claude Code, Codex, or another coding agent.

The prompt supplies the App ID, Program ID, revenue source, setup mode, and test environment values.

## Instructions for the agent

Before editing code:

1. Read the [manual setup contract](/docs/integrate-refkit/manual-setup.md).
2. Inspect the repository's framework, request path, authentication, first-party storage, billing flow, and tests.
3. Find the real landing request and account-creation path. Do not assume filenames or framework patterns.

Implement:

1. Read `via` on the live landing request.
2. Call authenticated `POST /v1/capture` from the backend.
3. Store `click_id` in the App's existing secure session, cookie, or database.
4. Call authenticated `POST /v1/identify` when the Customer account is created.
   * Send the stored `click_id`. Ordinary App API keys cannot use clickless promotion-code evidence. Never invent a click.
5. For Stripe, attach the exact returned `stripe_metadata` before creating the relevant Stripe object.
6. For API reporting, persist `customer_id` and `program_id`, then report successful payments, renewals, completed refunds, and the full dispute lifecycle with stable IDs. Keep combined refunds and active dispute exposure within the original payment.
7. Add tests using the repository's current test approach.
8. Run the relevant checks and verify the RefKit setup checklist.

Optional external automation:

1. Add one HTTPS handler for the selected RefKit lifecycle events.
2. Verify HMAC-SHA256 over `timestamp.rawBody` using `X-RefKit-Webhook-Timestamp` and `X-RefKit-Webhook-Signature` before processing the JSON body.
3. Treat delivery as best-effort and single-attempt. Do not assume RefKit retries failed requests.
4. For `payout.ready`, fetch `/v1/payout-executions/:id` with a live API key scoped to the exact App, execute payment in the existing finance system, then report `succeeded` or `failed` with a unique `Idempotency-Key`.
5. Keep payment execution outside RefKit and preserve the existing manual payout path.

Use the [outgoing webhook guide](/docs/integrate-refkit/outgoing-webhooks.md) for the complete event catalog, payload, headers, and verification example.

## Constraints

* Keep `REFKIT_API_KEY` server-side.
* Do not put capture only in code that runs at build time for a static landing page.
* Do not add Node.js or npm to a non-JavaScript App just to use RefKit. Call the REST API directly.
* Use the browser SDK only when server capture is not practical.
* Preserve the App's existing authentication, session, billing, and error patterns.
* Do not add unrelated dependencies, pages, or abstractions.

## Required handoff

Report:

* Files changed.
* Where `click_id` is stored.
* Where `/v1/identify` runs.
* How Stripe metadata or API-reported revenue is handled.
* Required environment variable names, without secret values.
* Tests and checks run.
* Any manual verification still required.

Agents can also use the [RefKit MCP server](/docs/reference/sdk-cli-mcp.md#refkit-mcp) to inspect setup status and manage RefKit resources.