---
title: "Read Status"
method: GET
path: "/api/autopilot/status"
tags: ["autopilot"]
---

# Read Status

`GET /api/autopilot/status`

## Request

- Base URL: `https://api.taxcompass.it` (the document declares no server; this is the origin it was published from)
- URL: `https://api.taxcompass.it/api/autopilot/status`
- Auth: HTTP bearer

What the dashboard needs to decide which modules to unlock.

## Response `200`

Successful Response

- AutopilotStatus: ``GET /api/autopilot/status`` — what the dashboard unlocks its modules on. ``profile_complete`` is the store's derived ``onboarding_complete``: every field the first FatturaPA document needs is stored. ``invoicing_ready`` adds the scheme check the router enforces on write, so a row saved before that gate existed reads as *not* ready instead of producing an invoice whose contributions we cannot compute. ``current_year`` is the fiscal year the server is working in — the client must not infer it from the browser clock, which may sit in another timezone on 31 December. ``verified_tax_years`` is which years the engine can actually answer a tax question for — the keys of ``tax.it_params.PARAMS``, which holds one verified, cited parameter set per year and refuses to extrapolate from a neighbouring one. The client needs it because the alternative is what shipped: a year switcher built from the browser clock (this year and the two before it), where two of the three options answered every time with "no verified tax parameters for 2025". A control whose options mostly fail is a control that teaches people the product is broken.
  - `profile_complete` boolean
  - `invoicing_ready` boolean
  - `current_year` integer, required
  - `verified_tax_years` integer[]

---

[API](https://skmtc.dev/taxcompass/apis/taxcompass-api.md) · [All operations](https://skmtc.dev/taxcompass/apis/taxcompass-api/llms.txt) · [OpenAPI document](https://skmtc.dev/taxcompass/apis/taxcompass-api/revisions/fef5fc6a9b91?raw)