---
term: 'Backend SDK (Software Development Kit)'
seoTitle: 'What is a Backend SDK? SDK vs API Explained'
headline: 'What is a Backend SDK?'
slug: backend-sdk
category: api-realtime
shortDefinition: 'A backend SDK is a toolkit of libraries and helpers that lets apps talk to a backend service in their own language, without raw HTTP.'
relatedTerms:
  - baas-vs-custom-backend
  - auto-generated-database-apis
  - database-abstraction-layer
  - backend-boilerplate-code
contrastsWith:
  - auto-generated-database-apis
faq:
  - question: 'What is an SDK in simple terms?'
    answer: 'A software development kit: the bundle of libraries, documentation, and tools that makes building against a platform practical. A backend SDK is the client-side member of the family — the library that turns a backend service''s HTTP API into native methods and typed objects in your app''s own language.'
  - question: 'What is the difference between an SDK and an API?'
    answer: 'The API is the contract — the endpoints, parameters, and responses a service exposes. The SDK is the toolkit that speaks that contract for you: native methods that build the requests, attach authentication, parse responses into typed objects, and handle errors. You can always use an API without its SDK; the SDK exists so you rarely want to.'
  - question: 'What does a backend SDK actually do under the hood?'
    answer: 'The plumbing you would otherwise write per call: compose the URL and encode parameters, attach the app keys and the user''s session token, serialize and deserialize between native objects and JSON, map HTTP errors to typed exceptions, retry sensibly, and keep session state across calls. One method call in your language; a correct, authenticated HTTP exchange underneath.'
  - question: 'What is the difference between a client SDK and a server SDK?'
    answer: 'Trust. A client SDK ships inside apps users hold, so it carries only publishable keys and every request is checked against permissions server-side. A server SDK runs in environments you control and may hold privileged credentials that bypass those checks. Confusing the two — shipping a privileged key in an app — is the classic SDK security failure.'
  - question: 'What is the difference between an SDK, a library, and a framework?'
    answer: 'A library is code you call; a framework is code that calls you, dictating structure. An SDK is a kit — typically one or more libraries plus documentation, tools, and samples — aimed at one platform or service. Every SDK contains libraries; not every library is an SDK; frameworks invert control in a way neither does.'
  - question: 'When should you use raw HTTP instead of the SDK?'
    answer: 'When the SDK does not fit the environment: an unsupported language, extreme binary-size constraints, edge runtimes where every dependency counts, or an unmaintained SDK trailing the API. Raw HTTP is always possible against a documented API — you re-inherit the plumbing the SDK was absorbing, so make it a deliberate trade, not a default.'
  - question: 'What makes a good SDK?'
    answer: 'It feels native to each language rather than machine-translated; it is typed, documented, and current with the API; errors are actionable; auth and retries are invisible; and its footprint is proportionate. The tell is the first ten minutes: a good SDK gets you from install to first successful call in one screen of code.'
  - question: 'Do backend platforms need one SDK per platform?'
    answer: 'Serious ones ship a family — web, the mobile platforms, and common server languages — because each ecosystem expects its own idioms, async patterns, and type systems. Coverage is a real selection criterion: the platform''s API is only as usable as the SDK for the platform you are building on.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Software development kit (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Software_development_kit'
  - name: 'SDK documentation hub'
    url: 'https://docs.parseplatform.org/'
  - name: 'JavaScript SDK guide'
    url: 'https://docs.parseplatform.org/js/guide/'
  - name: 'Back4app SDK quickstarts'
    url: 'https://www.back4app.com/docs'
cta:
  title: 'One backend, native everywhere'
  text: 'Back4app ships open-source SDKs for JavaScript, Flutter, Swift, Kotlin, and more — typed objects, session handling, queries, files, and live updates as native idioms on every platform, all speaking the same backend.'
  linkText: 'Start building free'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-07-27'
translationKey: backend-sdk
---

**A backend SDK is a toolkit of libraries and helpers that lets apps talk to a backend service in their own language, without raw HTTP.** The API is the contract; the SDK is the fluent speaker of it — and the difference between them is measured in the plumbing code your app no longer contains.

## Key takeaways

| Question | Answer |
| --- | --- |
| SDK vs. API | API = the contract; SDK = the toolkit that speaks it natively |
| What it absorbs | URLs, auth headers, serialization, errors, retries, session state |
| Client vs. server SDK | Publishable keys + enforced permissions vs. privileged trusted code |
| vs. library/framework | A kit of libraries for one platform; frameworks invert control |
| Selection criteria | Language coverage, typing, maintenance cadence, first-call speed |

## The plumbing, before and after

What one query costs in raw HTTP:

```javascript
// Raw HTTP: every call re-implements the plumbing
const res = await fetch(
  'https://parseapi.back4app.com/classes/Order?where=' +
    encodeURIComponent(JSON.stringify({ status: 'paid' })),
  {
    headers: {
      'X-Parse-Application-Id': APP_ID,
      'X-Parse-REST-API-Key': REST_KEY,
      'X-Parse-Session-Token': sessionToken,   // fetched and stored… by you
    },
  }
);
if (!res.ok) handleHttpError(res.status);       // mapped to what, exactly?
const orders = (await res.json()).results.map(hydrateOrder); // typing: yours
```

The same call through the SDK — with the session, serialization, and errors handled inside:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// One SDK call — session auth, serialization, retries all inside it
const query = new Parse.Query('Order');
query.equalTo('status', 'paid');
const orders = await query.find();
// The raw-HTTP version of this: build the URL, attach headers and
// session token, encode the where-clause, parse JSON, map types…
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// One SDK call — session auth, serialization, retries all inside it
final query = QueryBuilder<ParseObject>(ParseObject('Order'))
  ..whereEqualTo('status', 'paid');
final response = await query.query();
// Typed objects out; headers, tokens, and JSON handled inside the SDK
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// One SDK call — session auth, serialization, retries all inside it
let query = Order.query("status" == "paid")
query.find { result in
  if case .success(let orders) = result {
    render(orders)   // typed structs out; HTTP plumbing inside the SDK
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// One SDK call — session auth, serialization, retries all inside it
val query = ParseQuery.getQuery<ParseObject>("Order")
query.whereEqualTo("status", "paid")
query.findInBackground { orders, e ->
  if (e == null) render(orders) // typed objects out; plumbing inside the SDK
}
```

## Where the SDK sits

```mermaid
flowchart LR
  accTitle: How a backend SDK connects an app to a service
  accDescr: Application code calls native SDK methods; the SDK composes authenticated HTTP requests to the backend service's API and parses responses back into typed objects for the app.
  A["App code<br/>native methods, typed objects"] --> S["SDK<br/>auth · serialization ·<br/>errors · retries · session"]
  S -->|"HTTPS"| API["Backend API<br/>REST / GraphQL"]
  API --> B["Backend service"]
```

## SDK vs. API vs. library vs. framework

| Concept | What it is | Who calls whom | Example shape |
| --- | --- | --- | --- |
| API | The service's contract over the wire | You call it (somehow) | Endpoints + JSON |
| **SDK** | **Kit speaking one platform's contract** | **You call it, natively** | **Library + docs + tools** |
| Library | Reusable code for a task | You call it | A date-parsing package |
| Framework | Structure that runs your code | It calls you | A web or UI framework |

And the distinction that carries the security weight — **client SDK vs. server SDK**:

| Dimension | Client SDK | Server SDK |
| --- | --- | --- |
| Runs where | Users' devices and browsers | Infrastructure you control |
| Credentials | Publishable app keys only | May hold privileged keys |
| Permissions | Enforced server-side per request (ACLs, CLPs) | Can be trusted to bypass them |
| Golden rule | **Nothing secret ships in it** | **Its keys never leave the server** |

The classic breach in this vocabulary: a privileged server key pasted into a mobile app "temporarily." Client SDKs are designed on the assumption that everything in them is public — which is why the real security lives in the [data layer](/glossary/data-layer-vs-application-layer-security/), not the binary.

## Common use cases

- **Mobile and web apps on a BaaS** — the SDK *is* the backend interface: auth, data, files, and live updates as native calls.
- **Consuming third-party services** — payments, messaging, analytics: the vendor's SDK spares you their HTTP details.
- **Server-to-service integration** — server SDKs with privileged credentials doing admin work in trusted environments.
- **Multi-platform products** — one backend, four SDKs, four native idioms — the code tabs above are one query in four ecosystems.
- **Internal platform teams** — wrapping your own APIs in thin SDKs so product teams never hand-roll the plumbing twice.

## SDK or raw HTTP? A decision matrix

| Use the SDK when… | Go raw HTTP when… |
| --- | --- |
| Your platform is covered and maintained | The language has no (living) SDK |
| Auth and session handling matter | It's one unauthenticated call |
| You want typed objects and errors | Binary size is counted in kilobytes |
| The team spans skill levels | You're building your *own* SDK layer |
| Velocity beats control | The SDK trails the API you need today |

The honest framing: raw HTTP is always available against a documented API — the SDK is a convenience with compounding returns, not a lock. Prefer platforms where the SDKs are open source, so the convenience never becomes a black box.

## Limitations and trade-offs

- **An SDK is a dependency with a lifecycle.** Versions, breaking changes, and deprecations arrive on the vendor's schedule; pin, read changelogs, and prefer semver-disciplined publishers.
- **Abstraction hides the wire.** When something misbehaves, you debug through the SDK's layer — good ones log; great ones are open source so you can read the truth.
- **Coverage is uneven.** The flagship-language SDK is often excellent while the long tail lags; evaluate the SDK for *your* platform, not the docs' screenshots.
- **Bundle weight is real on clients.** Mobile and web budgets care about kilobytes; tree-shakeable, modular SDKs earn their place.
- **The SDK can't fix the API.** A confusing contract produces a confusing kit — SDK quality is downstream of API design.

## SDKs on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. The SDK family is the front door: [open-source kits](https://docs.parseplatform.org/) for JavaScript, Flutter, Swift, Kotlin/Android and more, each wrapping the same generated APIs with native idioms — typed objects, session management, queries with includes, file uploads, and live subscriptions. Client SDKs carry only publishable keys, with ACLs and class-level permissions enforced server-side on every call; privileged work stays in Cloud Code. One backend, every platform, no plumbing in your repositories.