onError

onError is your hook for logging and reporting when the widget can't start. It's narrower than the name suggests — see below.

Signature

interface MedosBookingConfig {
  onError?: (error: Error) => void;
}

When it fires

It fires when the initial load fails — either of the two blocking requests the widget makes on start:

• the workspace lookup (a rejected key, an invalid workspace, a network failure)
• the public doctor profiles lookup

Both are cases that stop the widget rendering a usable booking flow.

The widget shows its own error UI regardless — onError is there so you can send the failure to your logging service (Sentry, Datadog, etc.) or trigger a custom fallback.

Example — Sentry

import * as Sentry from "@sentry/browser";

MedosBooking.init({
  apiKey: "mk_...",
  onError: (err) => {
    Sentry.captureException(err, { tags: { source: "medos-booking" } });
  },
});

Example — inline banner

MedosBooking.init({
  apiKey: "mk_...",
  onError: (err) => {
    document.getElementById("booking-error").textContent = err.message;
  },
});

Config mistakes throw, they don't call onError

These are raised synchronously by init(), so catch them with try/catch — onError will not see them:

• "API key is required" — no apiKey passed.
• "containerId is required for inline mode".
• Container with id "X" not found — inline mode, missing DOM node.

try {
  MedosBooking.init({ apiKey: "mk_...", mode: "inline", containerId: "book" });
} catch (err) {
  console.error("Medos Booking failed to start:", err);
}

What reaches onError is the workspace-load failure described above, carrying the API's own message.

Don't rely on message strings for logic

Error message text can change between releases. If you need to branch on error type, ask the platform team about adding a stable error code — we're tracking that as a future improvement.