putio/sdk-dev
Develop or review put.io SDK repositories, API clients, and client libraries across TypeScript, Swift, Kotlin, and similar packages. Use when adding or changing namespaces, tightening request or error types, aligning SDK behavior with backend and app usage, updating SDK verification flows, or checking how an SDK repo should be documented and released.
90
Quality
90%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Securityby
Passed
No known issues
language-notes.mdreferences/
SDK Language Notes
Use the section that matches the SDK repo you are changing.
TypeScript
- Stay Effect-first when the repo already uses Effect.
- Keep
Schemaat boundaries for request, response, config, and error shapes. - Keep Promise and Effect clients aligned when both are public.
- Prefer discriminated unions, explicit exports, and parameter-aware return types over loose option bags.
- Preserve the typed surface; use unsafe casts or ignored type failures only with explicit approval.
Swift
- Prefer
async throwsand native Swift value types. - Keep the package surface open-source-safe and preserve package-manager install paths.
- Verify the example app when auth or integration behavior changes.
- Prefer coroutine-first APIs, typed public results, and Kotlin-native surfaces as long-term contracts.
Kotlin
- Prefer coroutine-first APIs.
- Keep models serialization-friendly.
- Prefer explicit error contracts over generic failures.
- Stay close to the TypeScript contract shape without forcing full endpoint parity.
- Preserve forward-compatible backend values when the server can evolve faster than the client.