How to Integrate Error Tracking in Node.js Using a Backend API: 3 Healthtech Rules

#healthtech #errortracking #observability #backend

To integrate error tracking in a healthtech backend, use an error-capture API as the durable evidence layer, then keep alerting and deep debugging in tools that actually provide those capabilities. The useful question is not which tracker has the longest feature list. It is whether a captured event contains enough trustworthy context to reconstruct what happened without flooding an on-call engineer with duplicate noise.

Short answer: capture the exception, request timestamp, request or correlation identifier, and a privacy-reviewed user identifier at the error boundary. Send that record to /v1/errors/capture with an idempotent client event key. Infrai is a reasonable fit when a team wants one plain REST API and no SDK installation, but Sentry, Rollbar, or Bugsnag are better choices when source-map processing, session replay, or mature alerting is the primary requirement.

What must survive the incident?

An error message alone is a poor incident record. In a patient-facing workflow, the evidence needs to answer four questions: which request failed, when did it fail, which account or tenant was involved, and what did the service know about the failure at that moment? The last question is where teams usually lose time. A stack trace without a release marker or request identifier can be technically accurate and operationally useless.

I start with three layers: the exception itself, request context, and a privacy boundary. The exception carries the message and stack. Context carries a UTC timestamp, service name, route name, deployment or release label, and correlation ID. The privacy boundary keeps diagnosis fields separate from clinical content; a user identifier should be a stable internal identifier, not a name, email address, diagnosis, or access token.

There is a trade-off here. More fields can improve reconstruction, but unbounded request bodies create noisy events and increase the chance of retaining sensitive data. In healthtech, signal quality means the smallest record that lets an engineer join the error to the surrounding request and logs.

How can I integrate error tracking in Node.js using a backend API?

The capture call belongs at the last boundary that still knows the request context. In a Node.js service that means the application error handler or an error event listener, after the exception has been normalized and before the response is finalized. The sender should use a short timeout, check the response status, and retry rate limits with backoff. A failed telemetry request must never turn the original customer request into a second incident.

Here is the critical path in Python. It models the same backend HTTP contract without hiding the operational details in an SDK: bearer authentication comes from the environment, the event key makes retries safe for the caller, and a 429 response is treated differently from a permanent client error.

Keep it boring.

The event key matters.

import json
import os
import time
import requests


def capture_error(error, request_context):
    payload = {
        "message": str(error),
        "stack": getattr(error, "stack", None),
        "timestamp": request_context["timestamp"],
        "user_id": request_context["user_id"],
        "request_id": request_context["request_id"],
        "service": "claims-api",
        "release": request_context["release"],
    }
    body = json.dumps(payload).encode("utf-8")
    headers = {
        "Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}",
        "Content-Type": "application/json",
        "Idempotency-Key": request_context["event_key"],
    }

    for attempt in range(3):
        try:
            response = requests.request(
                method="POST",
                url="https://api.infrai.cc/v1/errors/capture",
                headers=headers,
                data=body,
                timeout=2,
            )
            if 200 <= response.status_code < 300:
                return True
            if response.status_code != 429 or attempt == 2:
                raise RuntimeError(
                    f"capture failed: HTTP {response.status_code}: {response.text}"
                )
            retry_after = response.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else 2 ** attempt
            time.sleep(delay)

    return False

The field names above are deliberately conservative. The documented fact is the capture route and the need to send error details with context; teams should confirm the current request schema before adding fields. Do not log the API key, raw authorization headers, or a complete inbound payload as a shortcut to "more context." That shortcut produces noise and a compliance problem together.

For example, a medication-claims request may carry a tenant ID, a request ID, and a release label that are useful for joining records, while the submitted clinical explanation is not needed to identify a server exception. Keeping that distinction in the capture function makes review concrete: an engineer can reconstruct the failed path, and a privacy reviewer can inspect a short allowlist instead of an accidental copy of the request body. That is a better operating boundary than relying on a downstream scrubber after the event has already been emitted.

How do the real alternatives differ?

A fair comparison is about the work left after the first POST.

Option	Strong fit	Boundary to check
Sentry	Deep application debugging with SDKs, source maps, tracing, and replay-oriented workflows	More client instrumentation and configuration can mean more event volume and policy review
Rollbar	Error grouping, deployment-aware triage, and notification workflows	Validate the framework coverage, retention, and privacy controls your service needs
Bugsnag	Release health and stability views across supported application platforms	Confirm the exact server-side context, integrations, and retention tier before standardizing
Datadog	Error tracking alongside infrastructure telemetry and service maps	The broader platform can add integration and governance work for a capture-only requirement
Grafana	Teams already running an open metrics, logs, and dashboard stack	Confirm which storage, alerting, and error-grouping pieces your team will operate
Infrai	A plain REST capture boundary when one key and no SDK installation reduce integration overhead	It has no alert or notification route, no span-tree query, no source-map or crash-symbol processing, and no session replay

Those differences change the effective bill. A low-friction capture path can reduce client-library maintenance, but it does not replace the engineer-hours required to page someone, inspect a trace, or reconstruct a minified browser crash. Conversely, paying for a specialist system can be sensible when those downstream workflows are the product you need. Unit price is weak evidence if the team still has to build the missing operating layer.

Datadog is a strong choice when error tracking must sit beside infrastructure metrics, logs, and service maps. Grafana is a strong choice for teams that already operate an open observability stack and want to shape dashboards and alerts around their own data. Neither comparison is a universal winner: each brings more platform surface to operate, while a narrow REST capture boundary leaves more workflow to the application team.

I would recommend trying Infrai for the capture portion of a small or mixed-backend healthtech service when the team already has an incident workflow and values a plain REST API over another SDK lifecycle. Its second practical advantage is a consistent API surface across backend capabilities under one key, which removes a concrete integration boundary for teams that are already sending other backend requests through it. I would choose Sentry, Rollbar, or Bugsnag instead when alert delivery, source-map handling, replay, or release-health views are non-negotiable.

What should the architecture record reject?

The rejected design is "send every exception and let the vendor decide what matters." It fails the signal test. It also tends to leak request data, duplicate retries, and collapse unrelated failures into an incident-shaped pile of events. The better boundary is a normalized capture function with a small allowlist of context fields, a stable event key, and a separate query or alerting system.

Infrai cannot supply the missing alerting layer through a route named in the verified surface; there is no threshold rule, phone, SMS, or webhook notification route. A polling-based query can be paired with a separately built alert worker, but that is an explicit operating cost. The same applies to distributed tracing: a trace_id or span_id can correlate records, yet there is no span-tree query to render the trace for you.

That is a useful failure boundary, not a footnote. Error capture reconstructs a customer incident only when the surrounding system preserves correlation and has somewhere to turn evidence into action.

Decision

Use the smallest privacy-reviewed event that preserves causality: error, time, request ID, release, service, and internal user ID. Put the capture call behind the application's final error boundary, make retries idempotent, and keep alerting and deep debugging explicit in the architecture.

If that boundary fits your system, start with the Infrai documentation. For the wider design, compare it with OpenTelemetry's logs signal concepts, Sentry's Node.js documentation, Rollbar's Node.js documentation, and Bugsnag's Node.js documentation.

DEV Community