Generate production-ready SDK client libraries for any REST API

This skill drafts client SDK code for REST APIs, including API wrappers, request and response models, language-specific usage patterns, and typed errors. Its proposed organization separates the base client, resource classes, models, errors, pagination, and retry utilities. Resource classes should follow the API's resource hierarchy, with a usage example for every generated class.

Base-client patterns support Python and TypeScript, with a Python users resource for endpoint-specific methods. Client behavior includes bearer authentication, JSON request bodies, request timeouts, HTTP errors, empty responses, and explicit cleanup. They are starting points for an API-specific implementation, rather than a complete client library ready for production.

Use it when asked to generate an SDK, create an API wrapper, or derive typed client models from an actual REST contract. The contract must determine authentication, resource paths, response shapes, pagination, and permitted retry behavior. Generated code, dependencies, credentials, and external service behavior require verification before changes are applied.

Do not automatically replay non-idempotent writes. Retries are appropriate only for documented eligible operations within attempt and deadline budgets, with API-supported idempotency keys where needed. Retry-After may be a date or a duration; delays need caps and jitter. Destructive or costly actions still require the relevant authorization.

The output can include a shared client, typed models, per-resource operations, error classes, pagination helpers, and examples. Python models use dataclasses, TypeScript models use interfaces, and Go models use structs. SDK requests should identify the library and version through User-Agent. The Python client uses these dependencies:

import httpx
from typing import Optional
import time

Typed errors distinguish authentication, authorization, missing resources, validation, rate limits, and server failures. Error messages must avoid exposing response bodies or secrets. A TypeScript cast does not validate a response schema at runtime, and JSON handling needs separate treatment for binary or text endpoints. A 204 response or empty successful body should not be parsed as JSON.

The pagination example expects a page envelope containing data and total_pages. It cannot directly wrap the example UsersResource.list method, which returns only a list. Adapt cursor or page semantics to the real API, validate envelopes, and bound page counts, total items, and time.

Path identifiers need encoding, including embedded slashes, while query values should pass through the HTTP client's parameter encoder. Base URLs must stay on trusted HTTPS origins, and redirects must not leak authorization. Python clients need cleanup in a finally block or a context manager. These contract and lifecycle details are part of completing the draft before production review.