\n```\n\nContracts can also describe success and error bodies by status:\n\n```ts\nawait api.post('/transactions', transactionInput).contract({\n success: {\n default: CreatedTransactionSchema,\n 201: EmptyResponseSchema,\n },\n error: {\n default: ErrorSchema,\n 400: BadTransactionResponseSchema,\n 409: AlreadyCreatedTransactionResponseSchema,\n },\n})\n```\n\nSuccess status maps accept only `2xx` and `3xx` status keys. Error status maps accept only `4xx` and `5xx` status keys. Success map status keys control which non-2xx responses resolve; error contracts validate failed responses before `HttpError` is thrown.\n\nError branches validate failed HTTP responses before throwing `HttpError` with the validated error data. If an error response fails its own contract, 1000fetches throws `ContractValidationError` with the status, method, URL, response, schema, and original data.\n\n### Data Extraction\n\nThe method-based API provides clean data extraction with full type safety:\n\n```ts\n// Extract untyped data (without contract)\nconst data = await api\n .get('/users/:id', {\n pathParams: { id: '123' },\n })\n .data()\n// data 👉 unknown\n\n// Direct typed data extraction (with contract)\nconst user = await api\n .get('/users/:id', {\n pathParams: { id: '123' },\n })\n .contract(userSchema)\n .data()\n// user 👉 { id: number, ... }\n\n// Works with all HTTP methods\nconst newUser = await api.post('/users', userData).contract(userSchema).data()\n// newUser 👉 Fully typed user object\n\nconst updatedUser = await api\n .put('/users/:id', userData, { pathParams: { id: '123' } })\n .contract(userSchema)\n .data()\n// updatedUser 👉 Fully typed user object\n\n// Run the request and intentionally ignore response data\nawait api.delete('/users/:id', { pathParams: { id: '123' } }).void()\n```\n\n## ➡️ Design Trade-Offs\n\n1000fetches is intentionally small, but it is not just a thin `fetch` alias. It focuses on the features that tend to become repetitive in application code:\n\n| Capability | What 1000fetches Provides |\n| --------------------- | --------------------------------------------------------------------- |\n| **TypeScript** | Schema-inferred response types and typed path parameters |\n| **Path Params** | Compile-time and runtime checks for `:param` placeholders |\n| **Schema Validation** | Standard Schema support for Zod, Valibot, ArkType, and more |\n| **Retry Logic** | Opt-in retry policy with backoff, jitter, and `Retry-After` |\n| **Error Handling** | Structured errors for HTTP, network, timeout, and validation failures |\n| **Dynamic Defaults** | Per-request headers, params, timeout, retry, and fetch options |\n| **Middleware** | Request and response middleware with typed context |\n| **Tree Shaking** | Side-effect-free ESM/CJS builds |\n\n---\n\n## 📄 License\n\nMIT License - see [LICENSE](./LICENSE) for details.\n\n---\n\n\n\n**Built for developers who believe type safety shouldn't be optional.**\n**Because your backend deserves skepticism.**\n\n
\n\n\n\n[zod]: https://zod.dev/\n[valibot]: https://valibot.dev/\n[arktype]: https://arktype.dev/\n[standard-schema]: https://github.com/standard-schema/standard-schema\n","readmeFilename":"README.md"}