@connectedxm/admin 6.31.1 → 6.32.0

package/.claude/skills/applying-backend-diff/SKILL.md

@@ -0,0 +1,128 @@
+---
+name: applying-backend-diff
+description: Use when the user shares a backend PR, patch URL, or diff and asks to mirror, port, or add those API endpoint changes into the @connectedxm/admin-sdk TypeScript SDK (queries/mutations files under src/queries and src/mutations). Triggered by phrases like "update admin sdk with this diff", "mirror this endpoint", "add this to admin-sdk", "port these endpoints", or sharing a backend PR while in the admin-sdk repo or one of its worktrees.
+---
+
+# Applying a Backend Diff to admin-sdk
+
+## Overview
+
+Backend adds or changes an admin API endpoint → admin-sdk needs a matching query or mutation file. The repo enforces a **strict file shape** because `scripts/generate.ts` walks the AST to emit `openapi.json`, and deviations are silently dropped from the generated OpenAPI spec — and therefore from the downstream `@connectedxm/admin-sdk` typescript-axios package.
+
+The repo's [CLAUDE.md](CLAUDE.md) is the source of truth for conventions; this skill is the procedural recipe for going from a backend diff to a working, lint-clean SDK change.
+
+## When to use
+
+- User shares a backend PR URL (github.com, patch-diff.githubusercontent.com) and asks to update the SDK.
+- User pastes a diff and asks to mirror endpoints in admin-sdk.
+- User asks to "add this endpoint" to admin-sdk and provides backend code.
+
+**Don't use** for:
+- Hand-editing the generated `sdks/typescript/` package — it's regenerated from `openapi.json`.
+- Changes that don't involve adding/modifying API endpoints (e.g., dependency bumps, internal refactors).
+
+## Workflow
+
+### 1. Get the diff
+
+If the user gave a GitHub PR URL or a `patch-diff.githubusercontent.com` URL, fetch via `gh` CLI rather than WebFetch — patch-diff URLs redirect through auth and frequently 401:
+
+```bash
+gh pr view <num> --repo <owner>/<repo> --json title,body,files,additions,deletions
+gh api repos/<owner>/<repo>/pulls/<num>/files --jq '.[] | {path: .filename, patch: .patch}'
+```
+
+The PR description often names the pattern to mirror ("mirrors the existing X(...)") — read it before scanning code.
+
+### 2. Extract, per endpoint
+
+- HTTP method + URL path (e.g. `GET /payments/:paymentId/tax-metadata`)
+- Path / query params and their types
+- Request body shape (mutations only)
+- Response `data` shape — including all branches (soft-skip messages, error messages, success payload)
+
+### 3. Find the canonical example to mirror
+
+Locate the parent resource directory by grepping for an existing endpoint on the same resource:
+
+```bash
+grep -rln "/payments/" src/queries/ src/mutations/
+```
+
+Then mirror the closest-matching file:
+
+| Endpoint type | Canonical example | Wrapper helper |
+|---|---|---|
+| Single GET | `src/queries/<resource>/useGetX.ts` | `useConnectedSingleQuery` |
+| Paginated list | `src/queries/<resource>/useGetXs.ts` | `useConnectedInfiniteQuery` |
+| Cursor list | (find an existing one in the repo) | `useConnectedCursorQuery` |
+| Mutation | `src/mutations/<resource>/useUpdateX.ts` / `useCreateX.ts` / `useDeleteX.ts` | `useConnectedMutation` |
+
+### 4. Reuse existing types
+
+Before adding to `src/interfaces.ts` or `src/params.ts`, grep both files:
+
+```bash
+grep -n "^export.*<TypeName>\b" src/interfaces.ts src/params.ts
+```
+
+For **genuinely dynamic** response blobs (e.g., raw third-party transaction data, free-form metadata), `Record<string, any>` is supported by the generator — see `scripts/generate.ts:570`, which maps it to an OpenAPI `object` with `additionalProperties`. Don't invent a misleading concrete interface just to "stay consistent."
+
+### 5. Create the file with exact shape
+
+The AST parser at `scripts/generate.ts` looks for one exported arrow function whose first parameter type extends `SingleQueryParams` / `InfiniteQueryParams` / `CursorQueryParams` / `MutationParams` and whose return type is `Promise<ConnectedXMResponse<T>>`. Get this wrong and the endpoint silently drops from `openapi.json`.
+
+**Query file exports, in order:**
+1. `*_QUERY_KEY` — array key, nested under parent resource's key (e.g. `[...PAYMENT_QUERY_KEY(id), "TAX_METADATA"]`)
+2. `SET_*_QUERY_DATA` — cache setter
+3. Params interface extending `SingleQueryParams` / `InfiniteQueryParams` / `CursorQueryParams`
+4. `async` API function returning `Promise<ConnectedXMResponse<T>>`
+5. `use*` hook calling the appropriate `useConnected*Query`
+
+**Mutation file exports, in order:**
+1. Params interface extending `MutationParams`
+2. `async` API function (call `queryClient.invalidateQueries(...)` / setters after the request succeeds so consumers see fresh data)
+3. `use*` hook calling `useConnectedMutation`
+
+Path aliases `@src/*` and `@interfaces` are configured — use them.
+
+### 6. Regenerate barrels
+
+```bash
+npm run exports
+```
+
+Never hand-edit `index.ts` files — `.cursor/rules/index-exports.mdc` forbids it, and the script will overwrite manual edits.
+
+### 7. Verify
+
+```bash
+npx tsc       # typecheck (build uses tsup; tsc is noEmit)
+npm run lint
+```
+
+Both must pass clean before reporting completion.
+
+### 8. Do NOT run `npm run generate`
+
+CI regenerates `openapi.json` on the `staging` → `main` release PR per [.github/workflows/](.github/workflows/). Running it locally produces noisy unrelated diffs from other in-flight endpoints. Mention to the user that CI handles it.
+
+## Common mistakes
+
+| Mistake | Fix |
+|---|---|
+| File deviates from canonical shape → generator silently drops it | Diff your new file line-by-line against the closest existing file in the same directory |
+| Adding a new type that already exists in `interfaces.ts` / `params.ts` | Grep both files first; reuse types verbatim |
+| Hand-editing `index.ts` barrels | Run `npm run exports` |
+| Inventing a misleading concrete interface for a dynamic provider blob | Use `Record<string, any>` — the generator handles it |
+| Running `npm run generate` locally | Don't; CI does it on the release PR |
+| Using WebFetch on `github.com/.../pull/N.diff` | Use `gh pr view` and `gh api repos/.../pulls/N/files` instead |
+| `cd`-ing out of the current worktree | Stay in the worktree directory; use absolute paths |
+
+## Red flags — stop and reconsider
+
+- About to write a new interface without grepping for it first
+- About to edit `src/<dir>/index.ts` by hand
+- File shape doesn't match the canonical example (different export order, missing `SET_*_QUERY_DATA`, return type not `Promise<ConnectedXMResponse<T>>`)
+- Skipping `npx tsc` or `npm run lint` because "the change is small"
+- Running `npm run generate` to "make sure it works" — don't

package/.claude/skills/ship-to-prod/SKILL.md

@@ -1,35 +1,50 @@
 ---
 name: ship-to-prod
-description: Open a release PR from `staging` to `main` in this repo. Handles the full flow — gathers commits, pulls Linear ticket references from commit messages and the PRs that merged into staging, drafts a title and body that match the repo's PR template, picks reviewers, and (after the user confirms) creates the PR with `gh pr create`. Use this whenever the user says anything along the lines of "open a staging PR", "release staging", "ship staging to prod", "cut a release", "PR staging", "promote staging", "merge staging into main", or any variant of opening/preparing a PR between the staging and main branches. Prefer this skill over running `gh pr create` directly — the manual flow misses Linear references, the version-bump check, and reviewer conventions.
+description: Open a release PR into `main` in this repo. Handles the full flow — resolves the source branch from the user's prompt or the current checkout (never assumes `staging`), gathers commits, pulls Linear ticket references from commit messages and the PRs that merged in, drafts a title and body that match the repo's PR template, picks reviewers, and (after the user confirms) creates the PR with `gh pr create`. Use this whenever the user says anything along the lines of "open a release PR", "ship to prod", "cut a release", "PR into main", "promote this branch", "ship this branch", "release this", or any variant of opening/preparing a PR that targets `main`. Prefer this skill over running `gh pr create` directly — the manual flow misses Linear references, the version-bump check, and reviewer conventions.
 ---
 
-# Staging → Main release PR
+# Release PR into main
 
-Use this when the user wants to open a release PR from `staging` into `main` in the `connectedxm/admin-sdk` repo (npm package `@connectedxm/admin`). Production is `main` here — pushing to `main` triggers `publish.yml`, which publishes both `@connectedxm/admin` and the generated `@connectedxm/admin-sdk` (typescript-axios output of `sdks/typescript/`) to npm. The backend repo uses `prod`, but this SDK ships from `main`.
+Use this when the user wants to open a release PR into `main` in the `connectedxm/admin-sdk` repo (npm package `@connectedxm/admin`). The head branch is whatever the user names in their prompt; if they don't name one, fall back to the currently checked-out branch — never assume `staging`. (Production is `main` here — the backend repo uses `prod`, but this SDK ships from `main`.)
+
+Pushing to `main` triggers `publish.yml`, which publishes **two** packages to npm: `@connectedxm/admin` (the source SDK) and the generated `@connectedxm/admin-sdk` (typescript-axios output of `sdks/typescript/`, regenerated from `openapi.json`). There is no manual gate — merging this PR auto-publishes both packages.
 
 ## What you're producing
 
 A draft PR (or, on confirmation, an actual PR via `gh pr create`) with:
 
-1. **Base/head**: base `main`, head `staging` — never invent a feature branch
+1. **Base/head**: base `main`, head = the source branch resolved in step 1 — never invent a branch that the user didn't name and isn't the current checkout
 2. **Title** that reflects what's in the diff (see "Writing the title")
 3. **Body** matching `.github/pull_request_template.md`, with Linear refs harvested from commits AND from any sub-PRs they reference, plus the Semantic Versioning section ticked
 4. **Reviewers** drawn from the repo's collaborators (excluding the PR author)
 
-The user has asked to **always confirm before creating** the PR. Show the draft, wait for the go-ahead, then call `gh pr create`.
+The user has asked to **always confirm before creating** the PR. Show the draft, wait for the go-ahead, then push (if needed) and call `gh pr create`.
 
 ## Workflow
 
-### 1. Sync and check there's something to ship
+### 1. Resolve the branch and sync
+
+Pick the head branch for the release PR:
+
+- If the user named a branch in their prompt, use that.
+- Otherwise, use the currently checked-out branch (`git rev-parse --abbrev-ref HEAD`).
+
+If the resolved branch is `main`, stop and ask the user which branch to ship — you can't PR `main` into `main`. Treat the resolved name as `<source>` everywhere below.
+
+Then sync and check there's something to ship:
 
 ```bash
-git fetch origin main staging
-git log --oneline origin/main..origin/staging
+git fetch origin main <source>
+git log --oneline origin/main..origin/<source>
 ```
 
-If the log is empty, tell the user `staging` has nothing ahead of `main` — there's no PR to open. Stop.
+If the log is empty, tell the user `<source>` has nothing ahead of `main` — there's no PR to open. Stop.
+
+If `<source>` is behind `origin/<source>` locally, that's fine — the PR is opened against the remote refs, not your working copy. But mention it so the user knows.
 
-If `staging` is behind `origin/staging` locally, that's fine — the PR is opened against the remote refs, not your working copy. But mention it so the user knows.
+If `<source>` exists only locally (not on `origin`), you'll need to push it before `gh pr create` will work. Note that for step 10; don't push yet.
+
+If the branch already has an open PR against `main`, mention it (`gh pr list --head <source> --base main --state open`) and ask whether to add commits to that one or close it first. Don't open a duplicate.
 
 ### 2. Check the version bump (hard gate)
 
@@ -37,22 +52,22 @@ If `staging` is behind `origin/staging` locally, that's fine — the PR is opene
 
 ```bash
 git show origin/main:package.json | node -p "JSON.parse(require('fs').readFileSync(0,'utf8')).version"
-git show origin/staging:package.json | node -p "JSON.parse(require('fs').readFileSync(0,'utf8')).version"
+git show origin/<source>:package.json | node -p "JSON.parse(require('fs').readFileSync(0,'utf8')).version"
 ```
 
-Compare the two. If staging's version is **not** strictly greater than main's, stop and tell the user — they need to land a version bump on staging first (recent precedent: `chore: bump version to X.Y.Z` PRs into staging) before this release PR can pass CI. Don't open the PR; don't bump for them.
+Compare the two. If `<source>`'s version is **not** strictly greater than main's, stop and tell the user — they need to land a version bump on `<source>` first (recent precedent: `chore: bump version to X.Y.Z` commits) before this release PR can pass CI. Don't open the PR; don't bump for them.
 
 If the bump looks right, note which kind it is (major/minor/patch) — you'll tick the matching box in the body's Semantic Versioning section.
 
 ### 3. Gather the commits
 
 ```bash
-git log origin/main..origin/staging --pretty=format:'%H%x09%s%x09%b%x1e'
+git log origin/main..origin/<source> --pretty=format:'%H%x09%s%x09%b%x1e'
 ```
 
 The `%x1e` (ASCII record separator) lets you split multi-line commit bodies cleanly. You want the subject AND the body — Linear references like `closes ENG-1901` usually live in the body, not the subject.
 
-Skip merge commits whose subject starts with `Merge branch 'staging'` — they're noise from local merges, not a unit of work.
+Skip merge commits whose subject starts with `Merge branch` (e.g. `Merge branch 'staging'`, `Merge branch 'main'`) — they're noise from local merges, not a unit of work.
 
 ### 4. Resolve sub-PRs referenced in commit subjects
 
@@ -81,7 +96,7 @@ Collect refs from:
 - the body of every commit in step 3
 - the title and body of every sub-PR resolved in step 4
 
-**Only include refs you actually saw in those sources for this PR.** Don't carry refs over from prior staging→main PRs, recent conversation context, or memory of past releases — even if a ticket "feels relevant," it doesn't go in the list unless it's literally present in the commits/PRs you just gathered. Re-listing a ticket that was already shipped in a previous release is a real failure mode and confuses Linear's auto-close on merge.
+**Only include refs you actually saw in those sources for this PR.** Don't carry refs over from prior release PRs, recent conversation context, or memory of past releases — even if a ticket "feels relevant," it doesn't go in the list unless it's literally present in the commits/PRs you just gathered. Re-listing a ticket that was already shipped in a previous release is a real failure mode and confuses Linear's auto-close on merge.
 
 Dedupe. Preserve the verb the user wrote when possible — if a sub-PR said `closes ENG-1901`, your output should say `closes ENG-1901`, not `ref`. Only fall back to `ref` if the original said `ref` or no verb at all.
 
@@ -107,7 +122,7 @@ Look at what's actually in the diff before reaching for a template. The right ti
 
 **One dominant change:** copy the conventional-commit subject from the main commit/PR. Example: `feat(accounts): expose tier and tags on account responses`.
 
-**Several unrelated changes:** use a short generic title like `Staging Fixes` or a noun phrase that captures the theme. Look at recent staging→main PRs (`gh pr list --base main --head staging --state merged --limit 10`) to match the house style — they oscillate between conventional-commit and short noun phrases, both are fine.
+**Several unrelated changes:** use a short generic title like `Release fixes` or a noun phrase that captures the theme. Look at recent release PRs (`gh pr list --base main --state merged --limit 10`) to match the house style — they oscillate between conventional-commit and short noun phrases, both are fine.
 
 **Version-bump-only releases.** When the only thing in the diff is `chore: bump version to X.Y.Z`, a short title like `Release X.Y.Z` is fine.
 
@@ -145,7 +160,7 @@ Indicate the appropriate version bump for this PR:
 
 **Writing the testing plan.** Replace the template's default Testing checkboxes with a per-PR plan derived from what actually changed. The reviewer should be able to read the plan and know exactly what to verify before merging triggers the npm publish. Aim for 3–7 concrete checkbox items.
 
-Walk the file diff (`git diff --name-only origin/main..origin/staging`) and turn it into specific verification steps. This is a TypeScript SDK consumed by other apps (notably `admin-web`), so most verification happens via type-check + a smoke pass from a consumer. Note: this repo also generates a second SDK in `sdks/typescript/` from `openapi.json` via `npm run generate` / `npm run generate:sdks` — interface and param changes can affect what shows up there too.
+Walk the file diff (`git diff --name-only origin/main..origin/<source>`) and turn it into specific verification steps. This is a TypeScript SDK consumed by other apps (notably `admin-web`), so most verification happens via type-check + a smoke pass from a consumer. Note: this repo also generates a second SDK in `sdks/typescript/` from `openapi.json` via `npm run generate` / `npm run generate:sdks` — interface and param changes can affect what shows up there too.
 
 - **Query files** (`src/queries/<resource>/use*.ts`) → "Confirm `useGet*` returns the new field/shape; spot-check the query key and that 401/403/404/460/461 routes through `onNotAuthorized` / `onNotFound` / `onModuleForbidden`."
 - **Mutation files** (`src/mutations/<resource>/use*.ts`) → "Run the mutation from a consumer app and confirm the listed query keys invalidate / `SET_*_QUERY_DATA` updates as expected; on failure confirm `onMutationError` fires."
@@ -153,8 +168,8 @@ Walk the file diff (`git diff --name-only origin/main..origin/staging`) and turn
 - **Param/input shape changes** (`src/params.ts`) → "Confirm callers in `admin-web` still type-check against the new params; if a field became required, the consumer-side update needs to land before publish."
 - **`ConnectedXMProvider` / context changes** (`src/ConnectedXMProvider.tsx`, `src/hooks/useConnectedXM.ts`) → "Mount a consumer with the updated provider and confirm `adminApiParams`, `organizationId`, `getToken`, `getExecuteAs`, and the `onNotAuthorized` / `onModuleForbidden` / `onNotFound` / `onMutationError` callbacks still wire through."
 - **`AdminAPI` / axios changes** (`src/AdminAPI.ts`) → "Confirm `GetAdminAPI(params)` returns an axios instance with the expected `baseURL`, `organization`, `authorization`, `api-key`, and `executeAs` headers (when set)."
-- **OpenAPI generator changes** (`scripts/generate.ts`, `scripts/generate-sdks.ts`) → "Run `npm run generate` and inspect `openapi.json` for the expected diff; if the SDK output is in scope, run `npm run generate:sdks` and confirm `sdks/typescript/` regenerates cleanly. Note: the `staging` → `main` PR triggers `generate-openapi.yml`, which re-runs the generator on the PR branch."
-- **Index/barrel changes** (`src/index.ts`, per-folder `index.ts`) → "If files were added/moved, confirm `npm run exports` was run on staging (per `.cursor/rules/index-exports.mdc` — don't hand-edit). Then `npm run build` and inspect `dist/index.d.ts` to confirm the new symbols are exported."
+- **OpenAPI generator changes** (`scripts/generate.ts`, `scripts/generate-sdks.ts`) → "Run `npm run generate` and inspect `openapi.json` for the expected diff; if the SDK output is in scope, run `npm run generate:sdks` and confirm `sdks/typescript/` regenerates cleanly. Note: the PR triggers `generate-openapi.yml`, which re-runs the generator on the PR branch."
+- **Index/barrel changes** (`src/index.ts`, per-folder `index.ts`) → "If files were added/moved, confirm `npm run exports` was run (per `.cursor/rules/index-exports.mdc` — don't hand-edit). Then `npm run build` and inspect `dist/index.d.ts` to confirm the new symbols are exported."
 - **CI workflow changes** (`.github/workflows/`) → "Confirm `tests.yml`, `linear-check.yml`, `version-check.yml`, `publish.yml`, `approve.yml`, or `generate-openapi.yml` pass on this branch."
 - **Publish gate** → "After merge, confirm `publish.yml` runs cleanly on `main` and both `@connectedxm/admin@X.Y.Z` and the generated `@connectedxm/admin-sdk@X.Y.Z` are live on npm."
 
@@ -176,18 +191,24 @@ If there are zero Linear references, omit the bullet list and write `- (none)` u
 
 ### 9. Show the draft and wait
 
-Print the title, body, reviewer list, AND the version delta from step 2 back to the user, clearly labelled. Ask whether to create the PR as drafted, modify, or cancel. Don't run `gh pr create` until they've said yes.
+Print the title, body, reviewer list, the version delta from step 2, AND the push state from step 1 back to the user, clearly labelled. If a push is needed (`<source>` not on origin or local commits ahead of `origin/<source>`), state explicitly that creating the PR will push first. Ask whether to proceed, modify, or cancel. Don't run `git push` or `gh pr create` until they've said yes.
 
 The reason for confirming: the title and body are interpretive — you're summarizing several commits' worth of work. The user knows things you don't (which change is the headline feature, which is incidental cleanup, whether the Semantic Versioning box is right, whether something is already covered by another ticket). Five seconds of their attention up front beats editing the PR after the fact — especially since merging this PR triggers an npm publish.
 
-### 10. Create the PR
+### 10. Push the branch (if needed) and create the PR
 
-After confirmation, use a HEREDOC for the body so newlines and markdown survive:
+After confirmation:
 
 ```bash
+# Only if step 1 said the branch needed pushing:
+git push -u origin <source>   # first push
+# OR
+git push                      # subsequent push
+
+# Then:
 gh pr create \
   --base main \
-  --head staging \
+  --head <source> \
   --title "<title>" \
   --reviewer "<comma,separated,logins>" \
   --body "$(cat <<'EOF'
@@ -201,16 +222,18 @@ Return the PR URL from the command output so the user can click straight to it.
 ## Things to watch out for
 
 - **`main`, not `prod`.** This repo's production branch is `main` (the backend repo uses `prod`). Don't paste backend instincts here — `gh pr create --base prod` will fail.
+- **Don't assume `staging`.** Most feature work now branches off `main` and PRs directly back into `main`. Resolve the head branch from the user's prompt or the current checkout — never default to `staging`.
 - **Merging this PR publishes two packages to npm.** `publish.yml` runs on push to `main` and publishes both `@connectedxm/admin` (the source SDK) and `@connectedxm/admin-sdk` (the typescript-axios output regenerated from `openapi.json`). There is no manual gate. Take the testing plan seriously.
-- **The version bump is a hard gate.** If staging's `package.json` version isn't strictly greater than main's in plain `x.y.z` semver, `version-check.yml` will fail. Don't open the PR until the bump is on staging.
+- **The version bump is a hard gate.** If `<source>`'s `package.json` version isn't strictly greater than main's in plain `x.y.z` semver, `version-check.yml` will fail. Don't open the PR until the bump is on the source branch.
 - **`linear-check.yml` requires `ENG-####` in the body.** A `CXM-####`-only body will fail CI. If you only found `CXM` refs, surface that to the user before opening.
-- **`generate-openapi.yml` runs on the staging→main PR.** It regenerates `openapi.json` from the source. If the PR branch's `openapi.json` is stale relative to the source, expect this workflow to push a regen commit or fail. Don't be surprised by the extra activity on the PR.
+- **`generate-openapi.yml` runs on PRs to `main`.** It regenerates `openapi.json` from the source. If the PR branch's `openapi.json` is stale relative to the source, expect this workflow to push a regen commit or fail. Don't be surprised by the extra activity on the PR.
 - **Don't paste `<!-- CURSOR_SUMMARY -->` blocks** from sub-PR bodies into the new PR body. Those are auto-generated by the Cursor Bugbot reviewer and re-including them looks weird.
 - **Don't include the HTML comment placeholders** from the PR template (`<!-- A brief description -->`) in your output — replace them with real content.
 - **Keep the Semantic Versioning section.** Don't drop it from the body — the template explicitly includes it. Tick the box that matches the actual version bump.
 - **`closes` vs `ref`**: `closes` auto-closes the Linear ticket on merge to `main`. `ref` just links it. Preserve whichever the source commit/PR used. When in doubt, `ref` is the safer default — it doesn't change ticket state.
 - **Bot reviews are not human reviews.** Don't infer reviewer preferences from `github-actions` or `cursor` reviews on past PRs — those are automated. Look at human reviewers (`authorAssociation: MEMBER`) only.
 - **The author isn't a reviewer.** GitHub will reject `--reviewer <self>`. Always exclude `gh api user --jq '.login'` from the list.
+- **Don't push without confirmation.** Pushing exposes work to the team and triggers CI. Bundle it with PR creation behind the user's go-ahead.
 
 ## Why this exists
 

package/dist/index.cjs

@@ -1212,6 +1212,7 @@ __export(index_exports, {
   GetOrganizationWebhook: () => GetOrganizationWebhook,
   GetOrganizationWebhooks: () => GetOrganizationWebhooks,
   GetPayment: () => GetPayment,
+  GetPaymentTaxMetadata: () => GetPaymentTaxMetadata,
   GetPayments: () => GetPayments,
   GetPreferences: () => GetPreferences,
   GetPreset: () => GetPreset,
@@ -1426,6 +1427,7 @@ __export(index_exports, {
   OrganizationTriggerType: () => OrganizationTriggerType,
   PAYMENTS_QUERY_KEY: () => PAYMENTS_QUERY_KEY,
   PAYMENT_QUERY_KEY: () => PAYMENT_QUERY_KEY,
+  PAYMENT_TAX_METADATA_QUERY_KEY: () => PAYMENT_TAX_METADATA_QUERY_KEY,
   PREFERENCES_QUERY_KEY: () => PREFERENCES_QUERY_KEY,
   PRESETS_QUERY_KEY: () => PRESETS_QUERY_KEY,
   PRESET_QUERY_KEY: () => PRESET_QUERY_KEY,
@@ -1981,6 +1983,7 @@ __export(index_exports, {
   SET_PASS_TYPE_COUPONS_QUERY_DATA: () => SET_PASS_TYPE_COUPONS_QUERY_DATA,
   SET_PAYMENTS_QUERY_DATA: () => SET_PAYMENTS_QUERY_DATA,
   SET_PAYMENT_QUERY_DATA: () => SET_PAYMENT_QUERY_DATA,
+  SET_PAYMENT_TAX_METADATA_QUERY_DATA: () => SET_PAYMENT_TAX_METADATA_QUERY_DATA,
   SET_PREFERENCES_QUERY_DATA: () => SET_PREFERENCES_QUERY_DATA,
   SET_PRESETS_QUERY_DATA: () => SET_PRESETS_QUERY_DATA,
   SET_PRESET_QUERY_DATA: () => SET_PRESET_QUERY_DATA,
@@ -3180,6 +3183,7 @@ __export(index_exports, {
   useGetOrganizationWebhook: () => useGetOrganizationWebhook,
   useGetOrganizationWebhooks: () => useGetOrganizationWebhooks,
   useGetPayment: () => useGetPayment,
+  useGetPaymentTaxMetadata: () => useGetPaymentTaxMetadata,
   useGetPayments: () => useGetPayments,
   useGetPreferences: () => useGetPreferences,
   useGetPreset: () => useGetPreset,
@@ -20859,6 +20863,38 @@ var useGetPayment = (paymentId = "", options = {}) => {
   );
 };
 
+// src/queries/organization/payment/useGetPaymentTaxMetadata.ts
+var PAYMENT_TAX_METADATA_QUERY_KEY = (paymentId) => [
+  ...PAYMENT_QUERY_KEY(paymentId),
+  "TAX_METADATA"
+];
+var SET_PAYMENT_TAX_METADATA_QUERY_DATA = (client, keyParams, response) => {
+  client.setQueryData(PAYMENT_TAX_METADATA_QUERY_KEY(...keyParams), response);
+};
+var GetPaymentTaxMetadata = async ({
+  paymentId,
+  adminApiParams
+}) => {
+  const adminApi = await GetAdminAPI(adminApiParams);
+  const { data } = await adminApi.get(
+    `/payments/${paymentId}/tax-metadata`
+  );
+  return data;
+};
+var useGetPaymentTaxMetadata = (paymentId = "", options = {}) => {
+  return useConnectedSingleQuery(
+    PAYMENT_TAX_METADATA_QUERY_KEY(paymentId),
+    (params) => GetPaymentTaxMetadata({
+      paymentId,
+      ...params
+    }),
+    {
+      ...options,
+      enabled: !!paymentId && (options.enabled ?? true)
+    }
+  );
+};
+
 // src/queries/organization/sideEffects/useGetOrganizationSideEffects.ts
 var ORGANIZATION_SIDE_EFFECTS_QUERY_KEY = (triggerType, triggerId) => {
   const keys = [...ORGANIZATION_QUERY_KEY(), "SIDE_EFFECTS"];
@@ -44695,6 +44731,7 @@ var useUpdateTier = (options = {}) => {
   GetOrganizationWebhook,
   GetOrganizationWebhooks,
   GetPayment,
+  GetPaymentTaxMetadata,
   GetPayments,
   GetPreferences,
   GetPreset,
@@ -44909,6 +44946,7 @@ var useUpdateTier = (options = {}) => {
   OrganizationTriggerType,
   PAYMENTS_QUERY_KEY,
   PAYMENT_QUERY_KEY,
+  PAYMENT_TAX_METADATA_QUERY_KEY,
   PREFERENCES_QUERY_KEY,
   PRESETS_QUERY_KEY,
   PRESET_QUERY_KEY,
@@ -45464,6 +45502,7 @@ var useUpdateTier = (options = {}) => {
   SET_PASS_TYPE_COUPONS_QUERY_DATA,
   SET_PAYMENTS_QUERY_DATA,
   SET_PAYMENT_QUERY_DATA,
+  SET_PAYMENT_TAX_METADATA_QUERY_DATA,
   SET_PREFERENCES_QUERY_DATA,
   SET_PRESETS_QUERY_DATA,
   SET_PRESET_QUERY_DATA,
@@ -46663,6 +46702,7 @@ var useUpdateTier = (options = {}) => {
   useGetOrganizationWebhook,
   useGetOrganizationWebhooks,
   useGetPayment,
+  useGetPaymentTaxMetadata,
   useGetPayments,
   useGetPreferences,
   useGetPreset,