A REST API works in any language with no added dependency. An SDK wraps the API in typed, language-native methods. For most e-signature integrations the API is the better choice — here is why.
An e-signature integration is small — typically three endpoints: create envelope, send, handle webhook. That is not enough complexity to justify a third-party SDK dependency in a production system. Use the REST API directly; use an SDK only if you want typed autocomplete while prototyping.
An e-signature REST API is an HTTP interface your application calls directly — POST a PDF to create an envelope, GET to check status, receive webhooks on completion. An SDK (Software Development Kit) is a language-specific library that wraps the API, providing typed methods, token management, and error handling so you write less boilerplate. Both do the same thing; the SDK is a convenience layer on top of the API.
No. GetSigned is a plain REST API — any language with an HTTP client can integrate fully without an SDK. The Node.js, Python, PHP, Go, and Ruby guides on this site all use the standard library or a minimal HTTP client with zero e-signature-specific dependencies. An official SDK is available as an optional convenience.
Use the REST API directly when: you want zero additional dependencies in your codebase; you work in a language without an official SDK; you want full visibility into every request your system makes; or you are building a microservice where dependency minimalism matters. Direct API calls are also easier to audit and test — the requests are plain HTTP, inspectable with any proxy or logging tool.
An SDK makes sense when you want typed method signatures and autocomplete in your IDE rather than constructing JSON payloads by hand; when you want built-in retry logic and error class hierarchies; or when you are prototyping quickly and want to reach a working demo faster. For a production integration, the REST API is equally capable and adds no runtime dependency.
Not inherently, but any third-party dependency is a supply-chain risk surface. Each SDK dependency you add is code you did not write, maintained by a third party, and potentially subject to vulnerabilities. For a small, stable integration (create envelope, send, handle webhook — three endpoints), the argument for pulling in an SDK is weaker than for a large, complex API. If you use an SDK, pin the version and audit updates before upgrading.