SDK generation

SDK generation is the generation of client libraries (SDKs) for your API in the languages you need (JavaScript/TypeScript, Python, PHP, Go, etc.): instead of every integrator hand-assembling HTTP requests, headers and parsing responses, they install your package (npm, pip, composer, etc.) and call methods like ordinary functions — with autocompletion and types. We generate the SDK from your OpenAPI specification (see the “OpenAPI specs maintenance” service), polish the result (clear names, examples, a README), set up the build, versioning and publishing to package registries, and where possible automatic updates for backward-compatible API changes (breaking changes need review and a new major version, not a silent release). The point is to lower the integration barrier: with a good SDK a partner starts faster and makes fewer mistakes. Importantly and honestly: the quality of the SDK is the quality of your specification. It can be generated from any spec, but if it is incomplete or inaccurate, the SDK inherits its flaws — garbage in, garbage out; so part of the work is putting the specification in order (that is a separate service, but we will point it out). Also honestly: auto-generating an SDK is not a hands-off process. Auto-generation usually produces mechanical, hard-to-use code (awkward names, sparse examples) — so we refine it; and on every API change the SDK has to be regenerated, tested and republished — a process we build in. And about languages without illusions: each language is a separate build, tests and publishing, so making SDKs in five languages “just in case” is expensive and pointless — we take the ones your consumers actually integrate in, and we will help choose. If there is one consumer and one language, sometimes examples in the documentation are enough rather than a separate SDK — we will say so honestly. Picture this: a partner installs your package with one command, writes client.orders.create(...) with IDE hints — and the integration is ready in an evening, not a week. The base price starts from 75,000 ₽ per language: a guide for an API of medium complexity and a common language; a large or “bloated” API, a rare language and deep refinement take longer and cost more. It depends on the size of the API, the number of languages and the depth of refinement.

• Every integrator hand-writes HTTP requests to your API — slow and error-prone.
• Partners repeat the same plumbing (authorization, retries, parsing) on their side.
• The entry barrier is high — integration takes days instead of hours.
• When the API changes, everything breaks for consumers, and updating is hard.

• Generation of the SDK from your OpenAPI specification
• Support for the languages you need (JS/TS, Python, PHP, Go, etc.)
• Refinement: clear method names, types, examples, a README
• Authorization, error handling and retries inside the SDK
• Build, versioning and publishing to package registries (npm, pip…)
• Where possible — auto-generation and updates when the API changes
• Help with choosing languages for your real consumers
• Documentation on using the SDK

• Partners integrate faster — a package instead of manual plumbing
• Fewer mistakes — authorization and response handling are already inside
• API updates reach consumers through new SDK versions
• A lower entry barrier — integration in an evening, not a week

• We look at the specification, choose languages for your consumers
• We generate the SDK, refine it, set up publishing and versions
• We test on real calls, publish, and set up updating

• But the SDK is generated automatically — why pay?

  Generating the skeleton from the specification — yes, that is automated, and we do it. But “raw” auto-generation is often inconvenient: machine names, no examples, retries and publishing not set up. The work is to turn it into a library that is pleasant to use and to set up an update process. Plus the quality depends on the specification: a crooked spec means a crooked SDK, and that needs putting in order.

• How many languages should the SDK be in?

  Only the ones your consumers actually integrate in. Each language is a separate build, tests and publishing, so “five languages just in case” is wasted money and maintenance. Often you start with one or two most popular with the audience; we will help choose. If there is one consumer and one language, sometimes examples in the documentation are enough — we will say so honestly.

• What happens when the API changes?

  The SDK will have to be regenerated, tested and published as a new version — otherwise it will drift from the API. We automate regeneration from the specification where possible and build in versioning. Auto-updating is safe for backward-compatible changes; breaking ones are released as a new major version with review, not silently — so things do not break for consumers without warning. “Generate and forget” does not work with an SDK, and we say so upfront.