# SDK overview

The BugBoard SDKs are small, safe wrappers around the **[HTTP API](/docs/api-reference)**.
They give you named reporting helpers, a background queue, retries with backoff, and
graceful-shutdown flushing — so a report never blocks your app or gets lost.

There are two official SDKs, plus a dependency-free single-file option for any language:

| Language | Install | Guide | Source |
| --- | --- | --- | --- |
| JavaScript/TypeScript | `npm i bugboard` | **[Get started](/docs/sdks/javascript)** | [NPM Registry](https://www.npmjs.com/package/bugboard) |
| PHP | `composer require bugboard/sdk` | **[Get started](/docs/sdks/php)** | [Packagist](https://packagist.org/packages/bugboard/sdk) |
| Python | Under development | Coming soon… | Coming soon… |
| React Native | Under development | Coming soon… | Coming soon… |
| Flutter | Under development | Coming soon… | Coming soon… |

Already know which SDK you need? The **[framework guides](/docs/frameworks)** cover
installation, error-handler wiring and report delivery for Laravel, Symfony, plain PHP,
Express, NestJS, Next.js, Nuxt, SvelteKit, Remix, Vite SPAs and serverless runtimes.

> Prefer no dependency? Every SDK is optional — you can call the API directly from any
> language, or drop in the single-file **[custom implementation](/docs/custom-implementation)**.
> See the **[Quickstart](/docs/get-started/quickstart)** to send your first card.

## What the SDK does

BugBoard turns reported errors into **cards** on your project board. The SDK is a thin,
crash-safe wrapper over a single endpoint:

```text
POST https://bugboard.dev/api/v1/tasks
```

You don't build payloads by hand. Instead you call a **severity** method with a required
title, optionally a description (a string or the caught error) and tags — the SDK derives the
rest:

```ts
import bugboard from '@/utils/bugboard';

bugboard.critical('Checkout failed'); // just a title
bugboard.critical('Checkout failed', error); // add the error as the description
```

## The reporting surface

There's no `createCard`. Each SDK exposes exactly **16 severity/priority methods**, called
positionally as `method(title, description?, tags?)`:

|              | low           | **medium** (default) | high           |
| ------------ | ------------- | -------------------- | -------------- |
| **critical** | `criticalLow` | `critical`           | `criticalHigh` |
| **major**    | `majorLow`    | `major`              | `majorHigh`    |
| **moderate** | `moderateLow` | `moderate`           | `moderateHigh` |
| **minor**    | `minorLow`    | `minor`              | `minorHigh`    |

Most apps only need the four medium-priority methods — `critical`, `major`, `moderate`,
`minor`. The priority variants and the full contract are covered in the
**[API Reference](/docs/api-reference)**.

## Pick the right key for where the SDK runs

- **Servers** use a **secret** key (`bb_sec_…` + its `bbk_…` key id). Requests are
  HMAC-signed; the secret never travels on the wire.
- **Browsers / mobile** embed a **publishable** key (`bb_pub_…`) — public by design and
  write-only, sent as a bearer token.

See **[Choosing a key type](/docs/installation/choosing-a-key)** for guidance.

## Design guarantees

Every SDK is **non-blocking and crash-safe** (reporting returns immediately and never throws
into your app), **resilient** (timeouts, retries with backoff + jitter, honors `Retry-After`),
**bounded** (capped queue, optional sampling), and **safe by default** (HTTPS enforcement, a
`beforeSend` PII-scrubbing hook, client-side validation). Sending sensitive data? Every SDK
also supports **optional payload encryption** so the body is opaque in transit — even in the
browser network tab. See **[Encryption](/docs/security/encryption)**. The full contract and
design principles live in the **[API Reference](/docs/api-reference)**.