---
title: "Get Upstream Status Batch"
method: POST
path: "/api/skills/upstream-status/batch"
tags: ["skills"]
---

# Get Upstream Status Batch

`POST /api/skills/upstream-status/batch`

## Request

- Base URL: `https://app.thinqos.com` (the document declares no server; this is the origin it was published from)
- URL: `https://app.thinqos.com/api/skills/upstream-status/batch`
- Auth: none declared

Batch sibling of ``GET /{skill_id}/upstream-status`` (Sentry FE-28).

The skills catalog calls this once with every registry-installed skill id
instead of one request per skill. Drift comparisons use the source-level
catalog snapshots maintained by ``sync-skill-catalog``; this request makes
zero registry calls. Skills the caller can't read, that don't exist, or
whose latest source sync/snapshot is unavailable are omitted rather than
failing the whole batch. The badge is a non-blocking hint, so a missing
entry reads as "no update" client-side.

## Headers

- `x-impersonate-identity-id` string, nullable

## Request body

- UpstreamStatusBatchIn: Request body for the batch upstream-status endpoint (Sentry FE-28). The skills catalog used to fire one ``GET /{id}/upstream-status`` per registry-installed skill on page load (an N+1 the browser flagged). It now sends every id in one POST.
  - `skill_ids` string[], required

## Response `200`

Successful Response

- UpstreamStatusBatchOut: ``{skill_id: UpstreamStatusOut}``, keyed by stringified UUID. Skills the caller can't read, that don't exist, or whose upstream fetch fails are omitted - the badge is a non-blocking hint, so a missing entry is treated as "no update" by the client.
  - `statuses` object, required

## Other responses

- `422`: Validation Error

---

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