SDKs and integrations

Bicho has SDKs for JavaScript/TypeScript (browser and Node.js), PHP, Rust, and Python, plus an Astro integration built on the JavaScript SDK. All send OTLP/HTTP JSON to your own instance. Browser capture can be automatic. The Astro integration can report exceptions escaping server request middleware; direct Node.js, PHP, Rust, and Python capture is explicit.

SDK	Package	Capture and delivery
JavaScript / Node.js	@bicho-fyi/javascript	Automatic browser capture or explicit reporting; queued delivery with flush/close.
PHP	bicho-fyi/php	Explicit capture; synchronous delivery. PHP 8.2+.
Rust	bicho	Explicit capture; awaited delivery on Tokio. Rust 1.89+.
Python	bicho-fyi	Explicit capture; synchronous delivery. Python 3.11+.
Astro	@bicho-fyi/astro	Opt-in browser capture and SSR request-exception reporting; separate project configuration.

Existing Sentry SDKs and OpenTelemetry logs exporters are also supported integration paths.

Runnable examples

The bicho-examples repository includes browser, Node.js, PHP, Rust, Python, and Sentry Node examples using the real SDKs. Follow its README for installation and configuration, and use a dedicated test project: running a CLI example or submitting the browser form deliberately reports an error to your instance. Never put backend ingest secrets in a browser.

JavaScript and TypeScript

Install the published package:

npm install @bicho-fyi/javascript

The package includes TypeScript declarations and has no runtime dependencies. Its ESM entry point works in browsers and Node.js 24+ without starting collection on import. A standalone bundle is also available for browser script tags.

In browsers, initialization installs listeners for uncaught JavaScript errors and unhandled promise rejections by default. Caught exceptions and application-specific failures require explicit capture. You can disable listeners and report everything manually.

In Node.js, capture is always manual. Use an isolated createClient() per request when context and delivery state must not be shared. The SDK does not install process error listeners or change crash behavior. Await delivery before the process exits.

The JavaScript SDK uses public ingest keys only, including on the backend. It cannot authenticate a project that requires an ingest secret.

Read the JavaScript SDK guide for npm/ESM and script-tag setup, configuration, capture methods, filtering, and delivery limits.

• JavaScript SDK source
• JavaScript package on npm

PHP

Install with composer require bicho-fyi/php. The SDK uses native cURL and supports both public-key-only and secret-enabled backend projects. It does not install global error handlers or framework hooks. Each capture call blocks until acknowledgment or failure; there is nothing to flush.

Read the PHP SDK guide for configuration, exception capture, delivery failures, and retry identity. Source repository.

Rust

Install with cargo add bicho. Use it in Tokio services or the Rust side of a Tauri application. Capture is explicit and awaited; the SDK has no background queue or panic hook. Backend services can use an ingest secret; distributed desktop clients must use public-key-only projects.

Read the Rust SDK guide for configuration, event context, Tauri integration, and delivery. Source repository.

Python

The native Python SDK requires Python 3.11+ and has no runtime dependencies. Capture is explicit and synchronous, with no global hooks, logging handlers, or background delivery queue. Trusted backend applications can use an ingest secret.

Read the Python SDK guide for the pinned Git install, exception capture, privacy, delivery failures, and async application guidance. Python SDK source.

Astro

Install with npm install @bicho-fyi/astro. Enable browser capture on static or SSR sites, server request-exception reporting on SSR sites, or both with separate endpoints and public keys. Server reporting uses isolated clients and bounded delivery; prerenders, explicit error responses, and failures after streaming starts are not automatic captures. Both modes require public-key-only projects.

Read the Astro integration guide for configuration, published version requirements, delivery checks, and explicit reporting. Source repository.

Existing Sentry SDKs

Keep your SDK and error-capture calls, and replace the DSN with sentry.dsn from Bicho project registration. Disable integrations for tracing, replay, profiling, and other unsupported data types. Secret-enabled backend projects also require sentry.headers through the SDK transport.

Read Move from Sentry for configuration, delivery checks, tested SDK versions, and compatibility limits. This redirects new errors, not historical data.

Other languages and existing instrumentation

Choose an OpenTelemetry logs SDK, exporter, or logging bridge for your application language that supports OTLP over HTTP. Bicho accepts JSON and binary protobuf at POST /v1/logs. It does not accept OTLP/gRPC, traces, or metrics. You can send directly to Bicho or through an OpenTelemetry Collector; a Collector is optional and is not bundled with Bicho.

An exporter sends records your application emits. Installing or configuring one does not install exception capture. Your application or instrumentation must turn exceptions into log records with attributes such as exception.type, exception.message, and exception.stacktrace. Exceptions recorded only as trace events do not reach Bicho’s logs endpoint.

Bicho accepts exception records regardless of severity, plus plain ERROR/FATAL logs. It is not a general-purpose archive for lower-severity logs.

Use the endpoint and headers returned by project registration. Exporters must support X-Bicho-Key; secret-enabled backend projects also require X-Bicho-Secret. Keep secrets out of browser applications. Support for headers, environment-variable configuration, encoding, and exception logging depends on the exporter you choose, not just its language. Protocol support is not a tested compatibility claim for every exporter.

The OTLP ingestion guide covers exporter configuration, authentication, record shape, retry rules, deduplication, and payload limits. Stable occurrence UIDs matter when retrying: without one, a resent record can count as a new occurrence.

Capture and delivery are separate

JavaScript capture returns a queued occurrence UID; await flush or close to check delivery. PHP and Python calls block, and Rust calls must be awaited; those SDKs return a UID only after a valid collector acknowledgment. None of these UIDs is the server’s event lookup ID. All clients have retry and delivery limits. Follow the relevant SDK guide or your exporter’s flush and shutdown behavior.

Application metadata and stack text do not supply source-map debug IDs. The JavaScript SDK does not attach them, and ordinary OTLP exception attributes do not enable enrichment by themselves. Read source maps before relying on mapped frames.

Review privacy before sending custom data and operations for collector limits and deployment protections. Integrating an SDK or exporter does not grant investigation access: reads and administration use separate credentials.