---
title: "Get Active User Event"
method: GET
path: "/users/{user_id}/active_event"
tags: ["user-events"]
---

# Get Active User Event

`GET /users/{user_id}/active_event`

Get the user's closest-by-date active or planned event.

Back-compat surface for old mobile builds — always returns exactly one
event. New clients should call ``GET /user_events`` for the full
calendar.

The "no active event" case is an **expected, handled outcome**, not a
fault: the mobile onboarding probe (``auth_controller`` →
``_hasActiveUserEvent``) calls this on every launch and reads a 404 as
"no goal yet" — the normal state after cancelling/completing a goal, or
for a brand-new user. We therefore *return* the 404 instead of *raising*
``HTTPException``: Logfire's FastAPI instrumentation records every
exception raised inside an endpoint as a span ``exception`` event
(``is_exception=true``), so a raised 404 here floods the error views with
false positives that drown real failures (#1498). Returning the response
leaves the wire contract identical (same 404, same body) without emitting
an exception event. Same intent as the outbound-404 policy in
``cheshire/telemetry.py`` (#1478) — keep an expected 404 out of the error
views — but a different mechanism: that hook re-stamps the span *level* on
an httpx response, this one avoids recording the exception at all. The
*other* ``HTTPException(404)`` sites in this module signal genuinely-missing
resources and stay as raises, so a real 404 is still distinguishable in
telemetry (those carry an ``exception`` event; this one does not).

## Path parameters

- `user_id` string, nullable, required

## Response `200`

Successful Response

- object

## Other responses

- `422` — Validation Error

---

[API](https://skmtc.dev/imperfect/apis/imperfect-api.md) · [All operations](https://skmtc.dev/imperfect/apis/imperfect-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/imperfect/imperfect-api/revisions/cc2293a44257/schema)