---
title: "Reconcile Vendor Ids"
method: POST
path: "/v1/billing/vendor-ids/reconcile"
tags: ["billing"]
---

# Reconcile Vendor Ids

`POST /v1/billing/vendor-ids/reconcile`

## Request

- Base URL: `https://api.opero.pro` (the document declares no server; this is the origin it was published from)
- URL: `https://api.opero.pro/v1/billing/vendor-ids/reconcile`
- Auth: none declared

Live-check the org's cached Stripe/Metronome ids against the vendor's
real state and null whichever are confirmed gone, instead of trusting a
cache that never learns about a change made by hand in Stripe or
Metronome (e.g. a superadmin deleting a test Stripe customer in the
Stripe dashboard). Used by the superadmin panel's Refresh button and by
the delete-organization guard, so neither ever needs a manual SQL clear
for an id the vendor has already dropped.

A Stripe customer is "gone" when the retrieve 404s or answers with
`deleted: true` (Stripe keeps deleted customers retrievable forever with
that flag, per the API — it does not 404 them). A Metronome contract is
"gone" when the retrieve 404s, or "ended" when its own `ending_before`
(the same field `cache.py` reads for `term_end`) is in the past — either
is enough to clear both Metronome ids, matching the manual instructions
this replaces (confirm the contract has ended; Metronome customers are
not archived here).

Any other vendor error (5xx, timeout, auth) leaves the id untouched —
only a confirmed answer clears anything.

## Request body

- OrgIdBody
  - `org_id` string, required

## Response `200`

Successful Response

- unknown

## Other responses

- `422`: Validation Error

---

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