Ohdear Php Sdk Laravel Package

Technical Evaluation

Architecture fit. This is a thin, first-party HTTP client over Oh Dear's REST API, built on Saloon v4. It is framework-agnostic PHP: no service provider, no facade, no publishable config, no package auto-discovery. Treat it as an outbound integration adapter, not a "Laravel package" in the conventional sense. The correct placement is behind an application-owned interface (e.g. MonitoringProvider) so domain code never imports OhDear\PhpSdk\* directly, and the SDK stays replaceable.

Integration feasibility. High. Construction is a single token plus an optional timeout; methods map 1:1 to API resources; return values are typed DTOs with enums for check types, results, and uptime splits, which removes a whole class of string-matching bugs. The exception taxonomy is small and usable — ValidationException::errors() for field-level failures, OhDearException for everything else. Realistic first slice (config, container binding, one read path) is 1–2 engineer-days.

Technical risk.

• Saloon v4 is a hard dependency — the single largest install-time risk. If the app or any other SDK pins Saloon v2/v3, you have a conflict. Audit before committing.
• Adoption signal is thin: 73 stars, 0 dependents. Mitigated by the fact that it's maintained by the Oh Dear team itself (same org as the service) with changelog, releases, and a current release date — but you will be the battle test. No community corpus of edge cases to lean on.
• Synchronous HTTP in the request path. The 10s default timeout will blow any interactive latency budget. Every call must be queued or get a short explicit timeout plus a circuit breaker.
• createMonitor is not documented as idempotent. Onboarding flows will create duplicates on retry. Requires a monitorByUrl() pre-check plus a local unique constraint.
• Pagination semantics are unspecified. The README shows monitors() as an iterator but doesn't state whether it's lazy. On large accounts an eager iterator is a memory and latency fan-out.
• Outbound-only. No webhook/receiver surface evidenced. Inbound Oh Dear events need a separate path.
• Enum drift. CheckType and CheckResult cases will grow upstream; any exhaustive match over them is a latent fatal error.

Key questions.

1. What are the documented rate limits and 429 semantics, and does the SDK surface Retry-After?
2. Is there a webhook API, and is it exposed here or only via raw HTTP?
3. Does monitors() paginate lazily, and what is the page-size ceiling?
4. What is the support policy for Saloon major bumps and the PHP version floor?
5. Is createMonitor idempotent on url, or is there any natural key?
6. Are API tokens team-scoped and least-privilege, or account-wide?
7. Does a token scoped away from a team return 403 or 404 — and does the SDK distinguish them?

Integration Approach

Stack fit. Laravel 10/11/12 with PHP 8.2+ (verify Saloon v4's floor). Because there is no Laravel coupling, you own all wiring: a config/services.php entry for token and timeout, a singleton binding in a service provider, and the adapter class. Cache reads where the domain tolerates staleness — monitor lists, certificate health, check summaries — via Cache::remember with short TTLs. Never cache writes. For Http::-free testing, use Saloon's mock client rather than hitting the live API.

Migration path. Purely additive unless you already call Oh Dear with hand-rolled Guzzle or Http:: calls, in which case port call sites method-by-method and delete the legacy client afterward. Sequence:

1. Composer audit — composer why saloonphp/saloon, PHP floor, lockfile diff. This is the go/no-go gate.
2. Spike — authenticate against a sandbox Oh Dear team, exercise me(), monitors(), monitor($id). Confirm pagination behaviour empirically.
3. Build the adapter interface and move one read path behind it.
4. Wire the highest-value write path — either maintenance periods from the deploy pipeline or monitor provisioning on tenant creation.
5. Tests — mock-client unit tests plus a small contract suite against a real sandbox team, run in CI on a schedule.

Compatibility. Three surfaces: Saloon major version (largest), PHP version floor, and enum drift. Pin with a caret constraint, track the lockfile, and add a CI job that resolves the latest allowed minor so upstream additions surface before production does. Wrap all enum consumption with a default branch.

Sequencing. Reads before writes; reversible writes before irreversible ones. Concretely: read paths → snooze/unsnooze and start/stop maintenance (fully reversible) → create/delete monitor and status page (irreversible, needs guardrails) → status page update automation (public-facing blast radius, ship last).

Operational Impact

Maintenance. Low day-to-day — it's a thin first-party SDK — but you inherit the adapter, retry policy, and enum-drift handling. Budget roughly 0.25 FTE-days per quarter for version bumps and changelog review.

Support. Upstream is the Oh Dear product team, not a community. The README is effectively the API guide, with examples per resource — good enough that most integration questions are answered there. No evidence of an SLA or a community forum; assume small-vendor response times and keep integration ownership with your own on-call.

Scaling. You are bounded by Oh Dear's API rate limits, not by the SDK. The first thing to break will be per-tenant reads on page views — cache aggressively and prefer webhook/queue-driven refresh over request-time calls. Bulk provisioning (hundreds of tenants) must be chunked, queued, and backed off; a serial loop of createMonitor will be slow and will hit 429s. Iterating an entire account via monitors() is a fan-out risk worth a cap.

Failure modes and mitigations.

• API outage or latency — never fail tenant signup because Oh Dear is down. Provision as a queued best-effort job with a nightly reconciliation sweep.
• Token expiry or rotation — token from config/secrets, a rotation runbook, and an alert on repeated 401s.
• Timeout — set explicitly (3–5s interactive, longer for jobs), add a circuit breaker, and never call synchronously from a user-facing render.
• Duplicate monitors — monitorByUrl() pre-check plus a local unique index; accept a small race and dedupe in reconciliation.
• Partial bulk failure — track per-item results, retry idempotently, dead-letter the rest.
• Silent drift — a monitor deleted in the Oh Dear UI but still in your DB. Diff nightly.
• Enum drift — a new CheckResult case arriving in a patch release. Default branches everywhere.

Ramp-up. About one day for a mid-level Laravel developer to be productive: small surface, typed DTOs, documented examples. TPM effort is better spent upstream of the code — idempotency strategy, secrets handling, queue and retry policy, and reconciliation. The SDK solves none of those. Ship a one-page design note and a runbook before the first write path goes out.