Error tracking for API-only Laravel apps
API error tracking is different: no error page, just JSON and status codes. Here's how to catch real 5xx failures in an API-only Laravel app.
When your Laravel app serves a UI, a broken page is obvious — someone sees the red screen and tells you. An API has no such luxury. The client gets a 500 and a blob of JSON, your server moves on, and the only witness is a mobile app or a partner integration that may or may not bother to report it. API error tracking is its own discipline because the usual feedback loop — a human noticing something looks wrong — simply isn't there. On top of that, APIs generate a particular kind of noise: a steady stream of 422 validation responses that are working as intended and have nothing to do with bugs. The job is to catch the real failures and ignore the expected ones.
Why API errors hide
A few things conspire to keep API failures invisible:
- No rendered error page to eyeball during testing.
- Clients swallow errors — a background sync retries quietly and never tells anyone.
- Status codes blur together — 4xx and 5xx land in the same logs, and the meaningful ones drown.
- Validation is loud — 422s are normal traffic, not incidents, but they bury the 500s.
Without tracking, your first sign of a broken endpoint is a partner's angry email.
Separate the signal from the noise
The single most useful habit in API error tracking is distinguishing expected client errors from real server errors:
- 5xx — almost always your problem. Track every one.
- 422 / validation — usually the client's problem. Watch the rate, but don't page on each.
- 401 / 403 — auth issues; a spike is worth a look, individual ones aren't.
Group by endpoint and status so "POST /orders is throwing 500s" is one clear issue, not a thousand scattered lines.
Lookout fits API-only apps perfectly
Because Lookout's ingest is plain HTTP and JSON, there's nothing UI-shaped to get in the way — it's built for headless apps. Install from your app root:
composer require lookout/tracing
php artisan lookout:install
Configure with two env values:
LOOKOUT_LARAVEL=true
LOOKOUT_API_KEY=your-project-api-key
LOOKOUT_URL=https://your-lookout-host.example.com
The provider is auto-discovered. Unhandled exceptions from your API routes are reported and grouped by fingerprint, so a recurring 500 on one endpoint collapses into a single issue with a count — exactly what you want when no human is watching the responses.
Alert on real failures only
Set an alert rule on a threshold over a 1h or 24h window for your server errors, routed to Email or Slack. Keep validation responses out of the paging path — they're expected. Now a genuine spike in 500s on a checkout endpoint reaches you immediately, while the everyday 422s stay quiet. That separation is what makes alerts trustworthy instead of ignorable.
Bonus: one tool across the stack
If your API backs a mobile app or a JavaScript frontend, the same ingest contract covers those too — Swift, Kotlin, and browser JS report to the same project. A 500 in your API and the client error it caused can live side by side.
APIs fail in the dark. Give them a witness, separate the real errors from the routine ones, and you'll catch broken endpoints before your integrators do. Create a free Lookout project — 10,000 events a month, one project, no credit card — and put eyes on the responses no human is watching.