Skip to main content

obs-app-sdk

Python client for the obs-app.ctsoftware.co.uk ingestion API - send logs, metrics and traces from your application.

Install

pip install ct_obs_app

(the PyPI project is named ct_obs_app; the importable module is obs_app_sdk - see Quickstart below)

Get an API key

Log in at the obs_app dashboard and copy your API key from the profile page (rotate it there too, if needed). The SDK authenticates every request with it.

Quickstart

from datetime import datetime, timezone

from obs_app_sdk import Client, CaptureTrace

client = Client(api_key="your-api-key")

# Logging
client.log("Something happened", level=4)  # 1=Critical .. 5=Debug, default 4=Info
client.log(
    "Something happened",
    datetime=datetime.now(timezone.utc),  # defaults to time of receipt if omitted
    app="my-app", domain="example.com", container_id="ctr-1", logger_name="myapp.worker",
    extra={"user_id": 42},
)
client.log_batch([{"message": "a"}, {"message": "b"}])

# Metrics
client.add_metric(value=1.0, metric="request_duration_ms", auto_create=True)
client.add_metrics([
    {"metric": "request_duration_ms", "value": 12.3},
    {"metric": "queue_depth", "value": 4},
], auto_create=True)

# Traces - nested context managers build one tree, sent as a single request when the
# outermost one exits
with CaptureTrace(client, "handle_request", app="my-app"):  # app is optional; the inner spans take it from here
    with CaptureTrace(client, "query_db"):
        ...
    with CaptureTrace(client, "render_response"):
        ...

# Or submit logs/metrics/traces together in one request (validated all-or-nothing)
client.ingest(
    logs={"logs": [{"message": "started"}]},
    metrics={"metrics": [{"metric": "request_duration_ms", "value": 12.3}]},
    traces=[{"start": "...", "end": "...", "text": "handled"}],
)

Stdlib logging integration

import logging
from obs_app_sdk import Client, ObsAppLogHandler

client = Client(api_key="your-api-key")
logging.getLogger().addHandler(ObsAppLogHandler(client, app="my-app", domain="example.com"))

Each stdlib log record becomes one POST /api/log/ call. logger_name and datetime are filled in automatically from the record; app/domain/container_id are fixed tags you set once on the handler. For high-volume logging, call client.log_batch(...) directly instead of relying on the handler.

Reporting view errors

from obs_app_sdk import Client, capture_errors

client = Client(api_key="your-api-key")

@capture_errors(client, app="my-app", domain="example.com")
def my_view(request, user_id):
    ...

Wrap a view (or any function) with capture_errors. If it raises, the decorator sends an ERROR-level log (level=2) to the API with the exception message, the full traceback, and repr() of the call's args/kwargs under extra, then re-raises - your framework's normal error handling (e.g. a 500 response) still runs unchanged; this only observes. A failure while reporting (network error, bad API key, etc.) is swallowed so it can never replace or mask the original exception.

repr() of every argument is sent as-is (truncated past 2000 characters) - be mindful of passing secrets/PII as view arguments if that's a concern for your application.

Background (fire-and-forget) mode

client = Client(api_key="your-api-key", background=True, on_error=lambda exc: print("send failed:", exc))
client.log("Something happened")  # returns None immediately - queued, not yet sent

Pass background=True and every call is queued and sent from a single background thread instead of blocking the caller. Because the call has already returned by the time the request actually goes out, errors (auth, validation, rate limit, network) can't be raised back to the caller - they're only passed to on_error, if you provide one, otherwise dropped. Client.log returns None in this mode instead of the log id, since it isn't known yet. Only use this for data you can afford to lose occasionally (logs, metrics) - not for anything you need to confirm succeeded.

The queue is unbounded and the worker thread is a daemon, so anything queued right before the process exits can be lost. flush_on_exit=True (the default) registers an atexit hook that gives the queue a few seconds to drain; call client.flush(timeout=...) directly, or use Client as a context manager, for more control.

Error handling

All methods raise on non-2xx responses:

  • ObsAppApiKeyError - missing/invalid API key (HTTP 401)
  • ObsAppValidationError - invalid request data (HTTP 400); .errors holds the server's per-field error dict when there is one, else None
  • ObsAppRateLimitedError - HTTP 429. The API blocks the offending IP for 1 hour once its rolling rate-limit window trips - do not retry in a loop on this error, it won't help
  • ObsAppError - base class; also raised for network failures and unexpected status codes

Notes

  • This client is synchronous and makes one HTTP request per call - there is no background buffering/auto-flush thread. Use the batch methods (log_batch, add_metrics, ingest) to reduce request count for high-volume callers.
  • add_metrics (batch) only supports metric names, not metric_id - use add_metric (singular) for id-based lookups.

Metadata

Release files for ct-obs-app 0.2.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for ct-obs-app 0.2.0
File Size Uploaded Provenance Actions
ct_obs_app-0.2.0.tar.gz 14.7 kB With provenance Details for ct_obs_app-0.2.0.tar.gz

Built distribution (wheel)

Table of built distributions (wheels) for ct-obs-app 0.2.0
File Interpreter ABI Platform Actions
ct_obs_app-0.2.0-py3-none-any.whl Python 3 none any Details for ct_obs_app-0.2.0-py3-none-any.whl

Total release size: 27.8 kB

Release files / ct_obs_app-0.2.0.tar.gz

Download URL ct_obs_app-0.2.0.tar.gz
Size 14.7 kB
Tags Source
SHA-256 checksum
How to use checksums
aaaf4ee5a76c8db5b2db53bf76ec7b9a9c3e2724ad681607e51833a3c54b20f4
BLAKE2b-256 checksum
How to use checksums
b185c5ce4cb693455c047a4385d1a2155d42bc77c63831d8770ae483dd6cd4d7
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.16

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Nov 14, 2026.

Transparency log

Release files / ct_obs_app-0.2.0-py3-none-any.whl

Download URL ct_obs_app-0.2.0-py3-none-any.whl
Size 13.1 kB
Tags Python 3
SHA-256 checksum
How to use checksums
22f80f89b99f2ede0b6ef13b857c8767946cd53e83b643d3cca4f297a55384d5
BLAKE2b-256 checksum
How to use checksums
c9ac40ab2d5e5cf747e113ab30e52b4b88c9b2269c4cd73e7999c1d61bdb1a78
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.16

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Nov 14, 2026.

Transparency log

Security for ct-obs-app 0.2.0

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

Full provenance

Both files in this release have been uploaded with provenance metadata.

Select from 2 files

Attestation for ct_obs_app-0.2.0.tar.gz

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Nov 14, 2026.

Transparency log

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page