Laravel Glitchtip Laravel Package

Product Decisions This Supports

• Build vs. buy for GlitchTip administration. If your product needs to manage error-tracking resources — create projects, rotate DSN keys, invite users, configure alert rules, set up uptime monitors — this package is a thin, typed wrapper over the entire GlitchTip management API. The build-vs-buy answer tilts strongly to "buy": a hand-rolled Guzzle client is easy to start and expensive to keep correct, and the release notes show exactly why (see the is_up snake_case quirk, null-name 500s, updateKey() being a no-op on 6.2). Each of those is a bug your team would have shipped and debugged.
• Self-serve onboarding and tenant provisioning. The using() API (one client per account/credentials) makes it practical to provision a GlitchTip project and DSN per customer workspace at signup, then hand the DSN back to your app's config. This is the highest-leverage use case: it turns error tracking from an ops ticket into a product feature.
• Coverage as a roadmap guarantee. "Every operation in GlitchTip's OpenAPI spec is either implemented or excluded with a stated reason, and a test enforces it" is the single most important line in the release for planning purposes. It means you can scope a roadmap item against the OpenAPI spec and trust that the package won't quietly be missing an endpoint halfway through the sprint.
• Admin and internal-tooling features. Typed readonly data objects plus lazy() cursor pagination make it viable to build internal dashboards, project/user admin screens, and bulk operations (e.g. auditing keys across hundreds of projects) without paginating by hand.
• Observability surfaces in your own product. The stats() fixes (daily series now aggregated from hourly buckets) unlock customer-facing usage/health charts — "errors this week", "uptime", "usage vs. plan" — that previously required workarounds or returned wrong numbers. If you were blocked on daily-granularity reporting, that blocker is gone.
• Usage and billing-adjacent reporting on self-hosted. The corrected billing docs are a genuine planning input: usage, daily usage and overage status work on self-hosted from 6.1.3 / 6.1.4 / 6.2.1 respectively. Only Stripe plan/subscription/checkout/portal calls require Stripe billing. If a metered-plan or overage-reporting feature was assumed impossible on self-hosted, that assumption should be revisited.
• Safe-by-default write semantics. Retries apply to idempotent requests only, so a POST is never sent twice. For a PM this is a de-risking property: you can enable retry/backoff for reliability without opening the door to duplicate projects, duplicate invites, or duplicate alert rules — the class of bug that generates support tickets and manual cleanup.
• CI/CD and environment provisioning. Project/key creation scripted per environment (staging, previews, per-PR ephemeral environments) becomes a small, testable job rather than bespoke curl in a pipeline.

When to Consider This Package

Adopt when most of the following hold:

• You run or plan to run GlitchTip specifically (self-hosted or hosted) and need to manage it — projects, keys, users, teams, alert rules, monitors, stats — not merely send events.
• Your architecture is multi-tenant or multi-account, and you want using() to keep credentials scoped per tenant rather than threading an API token through the app.
• You value typed, IDE-friendly responses and pagination enough to prefer this over a 200-line in-house HTTP client.
• You're on a modern Laravel (the Guzzle 8 allowance targets Laravel 13 installs) and can track a young package's release cadence.
• You want endpoint coverage you can audit — the OpenAPI-parity test is a meaningful procurement signal that the surface is complete rather than "whatever the author needed".

Look elsewhere — or scope carefully — when:

• You need error ingestion, not administration. This is the management API. Sending exceptions is the Sentry-compatible SDK's job (sentry/sentry-laravel against a GlitchTip DSN). Do not let "Laravel GlitchTip package" in a ticket get confused with "instrument our app".
• You need webhooks or event-driven integration. Nothing in this release covers inbound notifications; polling stats() is a different architecture with different cost/latency tradeoffs.
• You need a version-support contract. Live integration is pinned to self-hosted GlitchTip 6.2.6. There's no stated support matrix for other versions. If you're on an older self-hosted instance or a hosted plan, validate against your instance before committing — several fixes here are explicitly version-sensitive (stats_v2 daily behaviour in 6.2, updateKey() no-op in 6.2).
• You're relying on billing automation. Only Stripe-backed plan/subscription/checkout/portal calls need Stripe billing; plan around that rather than assuming full billing coverage on self-hosted.
• You need battle-tested longevity. This is the first stable release, following a 1.0.0-RC line, with a single-maintainer bus factor. Acceptable for internal tooling and non-critical provisioning; treat it as a dependency to pin and monitor, not a platform foundational bet.
• usingSession() tempted you. Acting as a browser-signed-in user (shipping sessionid + csrftoken cookies and Django CSRF headers) is clever and useful for apps served from the GlitchTip instance's origin — but it's coupled to Django session/CSRF internals and is inherently fragile across auth changes. Sanction it only for same-origin, first-party tooling; don't build a customer-facing integration on it.
• You need rate-limit or quota handling. Not addressed in these notes; assume you own backoff policy beyond the idempotent-retry behaviour.

Practical adoption gate: stand up the opt-in live integration suite against a staging GlitchTip you control (tests/Integration runs create/update/delete and cleans up) and confirm the exact operations on your roadmap pass before committing.

How to Pitch It (Stakeholders)

To executives: We can now make error tracking a feature of our product instead of an ops chore. Every customer workspace can get its own GlitchTip project and key automatically at signup, with typed, tested code rather than a bespoke script — and a test suite that proves we cover the vendor's entire documented API. Because it's a small open-source dependency rather than a paid integration platform, cost is near zero and switching cost stays low: it wraps a standard HTTP API, so the exit path is "replace the client", not "re-architect". The honest caveat is maturity — this is a v1.0.0 with a single maintainer — which we mitigate by pinning the version and keeping usage confined to provisioning and internal tooling.

To engineering: Typed readonly DTOs, lazy() cursor pagination, per-account clients via using(), and retries restricted to idempotent requests so POSTs can't double-fire. OpenAPI parity is enforced by a test, so no endpoint is missing without a documented reason. Full write coverage is validated by an opt-in live suite against self-hosted GlitchTip 6.2.6. The release also closes several sharp edges we'd otherwise hit ourselves: monitor heartbeats always reading "down" (is_up snake_case), 500s on monitor updates without a URL and user updates without a name, social-app updates demanding a server URL, daily stats silently returning only the first hour of each day, and updateKey() being documented as a no-op on 6.2. Guzzle 8 is now allowed, so it installs cleanly on Laravel 13. Two things to hold in review: usingSession() depends on Django session/CSRF internals and should be limited to same-origin tooling, and the integration target is a specific self-hosted version — verify against our instance in staging before we depend on it.