feat: update billing-integration skill to lead with SDK usage#54
Conversation
Default to @credyt/api-client (TypeScript) and credyt-api (Python) over hand-crafted HTTP calls. Adds an SDK selection step, concrete initialisation snippets for both languages, and named SDK methods for each integration area. HTTP remains available as an option for other languages or explicit preference. Closes #53 Co-authored-by: Ben Foster <benfoster@users.noreply.github.com>
benfoster
left a comment
There was a problem hiding this comment.
@claude a few things to address.
Also we should include the direct docs page for each section in the skill in case the AI needs more help with the integration
e.g. the billing portal > https://docs.credyt.ai/quickstart/billing-portal
| - **Python** → `credyt-api` (`pip install credyt-api`) | ||
| - **Other language or preference for raw HTTP** → direct API calls with the `X-CREDYT-API-KEY` header | ||
|
|
||
| Ask if they'd prefer to use the SDK or hand-roll the HTTP calls. For TypeScript and Python users, lead with the SDK. The full SDK reference with examples for all three approaches is at [docs.credyt.ai/sdk](https://docs.credyt.ai/sdk). |
There was a problem hiding this comment.
Given the audience could be non-technical (e.g. vibe coders) we can first attempt to discover this based on the context of the AI tool in which we're running, falling back to asking the user with recommendations.
For example, Lovable, Bolt, Replit, V0 all default to Typescript. The LLM should know which platform it is running on. If using an AI coding assistant it should be able to make a decision based on the tech stack the user already has.
Final step will be a recommendation which the user has an option to override.
| ) | ||
| ``` | ||
|
|
||
| **Direct HTTP:** Attach `X-CREDYT-API-KEY: <key>` to every request. Show them how to create a helper function or configured HTTP client instance that sets this header automatically. |
There was a problem hiding this comment.
We're not "showing them" - we just do it. This skill should be handling the integration, not expecting the user to wire it up themselves.
|
|
||
| Key points: | ||
| - Use `external_id` to link the Credyt customer to their app's user ID | ||
| - Use `externalId` / `external_id` to link the Credyt customer to their app's user ID |
There was a problem hiding this comment.
No need to reference the SDK fields - this will be apparent in the samples. So can leave to external_id
| Help the user wire Credyt into their application code. This skill works with the user's actual codebase — reading their existing code and adding Credyt integration in the right places. | ||
|
|
||
| The full integration guide with code examples is at [docs.credyt.ai/ai-integration.md](https://docs.credyt.ai/ai-integration.md). Fetch it for detailed patterns and examples when needed. | ||
| The full integration guide is at [docs.credyt.ai/ai-integration.md](https://docs.credyt.ai/ai-integration.md). SDK references with code examples are at [docs.credyt.ai/sdk](https://docs.credyt.ai/sdk). |
There was a problem hiding this comment.
All code examples in the docs have also been updated with HTTP, Typescript and Python examples. If the AI is unsure how to do something, they can consult the individual pages in the docs.
| If the product uses a recurring fixed fee (e.g. $20/month), the customer must pay upfront before their subscription activates. In this case the API returns a `pending` status rather than activating immediately. | ||
|
|
||
| Set `return_url`, `failure_url`, and `redirect_to` on the subscription creation call so Credyt knows where to send the customer after payment — before you ever redirect them anywhere: | ||
| Set `returnUrl` / `return_url`, `failureUrl` / `failure_url`, and `redirectTo` / `redirect_to` on the subscription so Credyt knows where to send the customer after payment — before you ever redirect them anywhere: |
There was a problem hiding this comment.
Rather than trying to show the SDK specific field format, let's only show the api format (snake_case) and add a note at the top of the article on the casing of fields i.e. Typescript will be camelCase , python will be snake_case
|
Claude finished @benfoster's task in 3m 33s —— View job Changes pushedAll review feedback addressed in 717011a:
|
- Auto-detect language/platform from context before asking user - Add field casing note (API=snake_case, TS SDK=camelCase, Python SDK=snake_case) - Skill handles integration directly instead of showing users what to do - Simplify field references to snake_case API format throughout - Add docs links to each integration section - Update SDK method references to drop per-field signatures Co-authored-by: Ben Foster <benfoster@users.noreply.github.com>
|
@claude thiink you hallucinated a few of those links mate Customer creation → docs.credyt.ai/quickstart/customers We may also want to include some additional information about the customer signup flow. If the user wants to include promotional or bundled signup credits these can be done:
|
|
Claude finished @benfoster's task in 1m 3s —— View job Changes pushed
All done in 221e82b: Doc link corrections:
Signup credits: Added a "Promotional or bundled signup credits" subsection at the end of section 2 (Customer creation), covering both approaches — one-off wallet adjustment and entitlements — with their correct doc links and a note for the skill to ask the user which fits their use case. |
…egration skill Co-authored-by: Ben Foster <benfoster@users.noreply.github.com>
Updates the billing-integration skill to default to the TypeScript and Python SDKs over hand-crafted HTTP calls, as requested in #53.
What changed
How to test
claude --plugin-dir ./claude-plugins/credytand run the billing-integration skillTrade-offs
Generated with Claude Code