Sync - Hoard

Check pending

Check if the server wants Hoard to sync.

GET /api/v1/sync/pending

curl example

curl -H "Authorization: Bearer YOUR_API_KEY" \
  https://www.tryhoard.com/api/v1/sync/pending

Response:

{
  "action": "wait",
  "reason": "no_sync_needed",
  "sync_requested": false
}

Response fields

Field	Type	Description
`action`	string	`"sync"` — run a cycle now. `"wait"` — poll again later.
`reason`	string	Why the server made this decision. See values below.
`sync_requested`	boolean	Whether a sync was explicitly requested by the user from the dashboard.
`paused_until`	string	ISO-8601 end of the active pause window. Present for `sync_maintenance` and `tcgplayer_maintenance`.
`plan_error`	string	Why the sync plan could not be built. Present for `plan_error`.
`first_sync`	boolean	Present on `action: "sync"` responses. Always false.
`kind`	string	Present on `action: "sync"` responses. The scope of the requested cycle, for example `full` or `pricing`.
`plan`	object	Present on `action: "sync"` responses when the account uses dependency-aware planning and the agent sent a `capabilities` query param. Holds the step list for this cycle.
`account_settings`	object	Present on `action: "sync"` responses. Per-account behavior toggles the agent applies during the granted cycle. Currently one key: `auto_read_announcements` (boolean) — when true, the agent marks TCGplayer set-release announcement message threads as read at the end of the cycle.

`reason` values

Value	Meaning
`manual_request`	A sync is pending — either the user clicked “Sync Now” or the scheduler decided the interval has elapsed
`no_sync_needed`	No action needed, poll again
`in_progress`	A sync is already running
`auto_sync_paused`	Auto-sync is disabled for this account
`sync_maintenance`	Hoard has paused new sync admission for fleet maintenance; retry after `paused_until`
`tcgplayer_maintenance`	TCGplayer is in its daily maintenance window
`plan_error`	The sync plan could not be built from the capabilities the agent advertised; see `plan_error`. The request is consumed, so retry after advertising the missing capability

Clients do not need to distinguish manual from scheduled — the server is the single decision-maker. The original trigger is recorded server-side on sync_cycle_logs.trigger_source for analytics.

Sync status

Where the account is in the sync pipeline right now, and when prices last changed.

GET /api/v1/status

Works with a Bearer token or a signed-in browser session. The dashboard polls it every five seconds during Sync Now and once a minute otherwise.

curl example

curl -H "Authorization: Bearer YOUR_API_KEY" \
  https://www.tryhoard.com/api/v1/status

Response:

{
  "sync_in_progress": false,
  "sync_started_at": "2026-09-02T20:25:36Z",
  "last_sync_at": "2026-09-02T20:26:50Z",
  "last_cycle_completed_at": "2026-09-02T20:26:50Z",
  "agent_last_seen_at": "2026-09-02T20:27:00Z",
  "sync_mode": "full",
  "phase": "idle",
  "repriced_at": "2026-09-02T20:26:50Z",
  "prices_live_at": "2026-09-02T20:27:52Z",
  "repricing_cards": 4677,
  "repricing_expected_seconds": 64
}

Response fields

Field	Type	Description
`sync_in_progress`	boolean	Whether a sync is running (agent export or server repricing).
`sync_started_at`	string	ISO-8601 start of the current or most recent sync, or null.
`last_sync_at`	string	When Hoard last finished computing prices, or null. Only moves on the price path.
`last_cycle_completed_at`	string	When the most recent cycle of any kind (orders, refunds, full, pricing) reached a terminal state, or null.
`agent_last_seen_at`	string	Last agent heartbeat, or null.
`sync_mode`	string	`read_only` or `full`.
`phase`	string	Which stage is running. See values below.
`repriced_at`	string	Same instant as `last_sync_at`; named for the dashboard sentence.
`prices_live_at`	string	When prices were last written to TCGplayer, or null if never pushed.
`repricing_cards`	integer	How many inventory cards a repricing pass covers.
`repricing_expected_seconds`	integer	Median of the account’s last five server-side repricing passes, in seconds. Null until one has completed.

`phase` values

Value	Meaning
`exporting`	The agent is exporting from TCGplayer and uploading to Hoard
`repricing`	Hoard is computing new prices
`push_queued`	Prices are computed and a TCGplayer update is waiting for the agent’s next check-in
`pushing`	The agent is writing prices to TCGplayer
`idle`	Nothing is running

Read-only accounts never report push_queued or pushing, even if a stale push task exists from before the mode changed.

Agent heartbeat

Signal that Hoard is alive and check for updates.

POST /api/v1/heartbeat
Content-Type: application/json

Request body (optional):

{
  "version": "0.4.9",
  "platform": "darwin/arm64",
  "state": "syncing",
  "supported_tasks": ["apply_pending_price_updates", "refresh_orders"]
}

Request fields

Field	Type	Required	Description
`version`	string	No	Agent version. Required together with `platform` for the update check to run.
`platform`	string	No	Platform (e.g., `darwin/arm64`).
`state`	string	No	Send `"syncing"` while a sync cycle is running. Omit otherwise. When it is not `"syncing"`, the server auto-clears a stale sync lock and may hand out idle-time work.
`supported_tasks`	array	No	Task types this build can execute. The server intersects the list with the task types it knows about and stores the result. A task type missing from this list is never dispatched to the agent.

Response:

{
  "update_available": false,
  "force_update": false,
  "update_required": false,
  "product_lines": [
    {"name": "magic", "category_id": 1},
    {"name": "pokemon", "category_id": 2}
  ],
  "has_pending_tasks": false,
  "sync_mode": "read_only",
  "upload_approved": false,
  "sync_in_progress": false,
  "sync_started_at": null,
  "orders_refresh_due": false
}

Response fields

Field	Type	Description
`update_available`	boolean	Whether a newer Hoard version is available.
`force_update`	boolean	Whether the local install must update before continuing (kill-switched version).
`update_required`	boolean	Reserved. Always false.
`latest_version`	string	Latest version string. Only present when `update_available` is true.
`download_url`	string	URL to download the new binary. Only present when `update_available` is true.
`signature`	string	Ed25519 signature for verifying the download. Only present when `update_available` is true.
`sha256`	string	SHA-256 checksum for verifying the download. Only present when `update_available` is true.
`product_lines`	array	Product lines configured for this account. Each has `name` and `category_id`.
`has_pending_tasks`	boolean	Whether pending tasks or supported expired claims need a claim request. Temporary price blocks suppress the signal; expired Watch Only/unentitled price claims can signal cancellation. False during maintenance.
`sync_mode`	string	`read_only` or the account’s auto-push mode.
`upload_approved`	boolean	Whether the agent may run the autonomous price-push flow. False during a maintenance pause.
`sync_in_progress`	boolean	Whether the server is still processing this account’s uploaded inventory.
`sync_started_at`	string	ISO-8601 start time of the in-flight sync, or null.
`order_lookback_days`	integer	Per-account override for the order-sync lookback window. Only present when set; the agent clamps it to 7 to 120 days.
`orders_refresh_due`	boolean	Whether the agent should run an out-of-band orders refresh. False during a maintenance pause.
`tcgplayer_paused_until`	string	ISO-8601 end of the fleet-wide TCGplayer maintenance pause. Only present while paused. Agents stop all TCGplayer work until it passes.
`market_depth_tasks`	array	Product ids assigned for market-depth investigation this cycle. Only present when the account is idle and work was claimed.

Accounts without a paid entitlement are held read-only: sync_mode is pinned to read_only regardless of the stored value, upload_approved is always false, and pending price-push tasks are cancelled. An expired supported price claim can still set has_pending_tasks so the claim endpoint can cancel it. Price tasks blocked by consent, billing, or automatic-pricing pauses remain queued but do not set has_pending_tasks, leaving the agent free for other eligible work. They become visible again when the block clears. Watch Only or loss of entitlement cancels pending price tasks on heartbeat or claim. Heartbeat leaves claimed tasks intact, but advertises supported claims older than 10 minutes so an idle agent calls claim. Claim then recovers expired work or cancels price work for Watch Only/unentitled accounts. Fresh claims remain completable. Ready rollbacks and published Quick Add work remain visible during pricing pauses. Rejected Quick Add rows and fresh in-flight listings do not bypass pauses. Historical non-rejected pending listings become retryable after 30 minutes. New member-owned additions stay held until inventory confirmation; an uncertain additive upload is never replayed automatically in either delivery mode.

Upload inventory

Upload a gzipped inventory CSV from TCGplayer.

POST /api/v1/sync
Content-Type: application/gzip
X-Product-Line: magic
X-Sync-Cycle-ID: 20260831-abc123

The request body is the gzip-compressed CSV data. The server queues it for processing, matches cards to the catalog, and calculates price updates.

Header	Required	Description
`Content-Type`	Yes	Must be `application/gzip` or `application/octet-stream`
`X-Product-Line`	No	Which product line this upload belongs to (e.g., `magic`, `pokemon`, `yugioh`). Must match a configured product line.
`X-Sync-Cycle-ID`	No	Stable client-generated cycle identifier, also sent to `/sync/log`, so the V3 worker and agent trace update one cycle.

Response (HTTP 202):

{"status": "accepted"}

Error responses:

Code	Error code	Meaning
413	`payload_too_large`	Request body exceeds 10 MB on the wire
413	`decompressed_too_large`	Decompressed gzip body exceeds 50 MB
422	`invalid_csv`	CSV could not be parsed
422	`invalid_gzip`	`Content-Type` is `application/gzip` but the body is not valid gzip
422	`invalid_product_line`	X-Product-Line value not configured for account
422	`csv_processing_failed`	Unexpected error processing the CSV
503	`sync_paused`	New sync admission is paused for maintenance; honor the `Retry-After` header

Upload inventory (V4 presigned-URL flow)

Newer agent builds upload the CSV directly to Cloudflare R2 using a short-lived presigned PUT URL, then notify Hoard with the resulting R2 key. Hoard’s bandwidth and Ruby heap never see the bytes. The flow is three calls:

POST /api/v1/sync/upload-request — Hoard returns a 10-minute presigned PUT URL.
PUT <upload_url> — agent uploads the CSV bytes directly to R2.
POST /api/v1/sync with Content-Type: application/json and body {key, product_line, sync_cycle_id} — Hoard validates the key, creates the canonical cycle placeholder, enqueues the worker, and returns 202.

The presigned-URL flow is the only sync path on the server; it is not gated by any per-account flag. The raw-CSV POST documented above is still accepted for older agents, and internally writes the body to R2 before queueing the same worker.

Step 1: Mint a presigned URL

POST /api/v1/sync/upload-request
Content-Type: application/json

Request body (optional):

{"product_line": "Magic"}

Response (HTTP 200):

{
  "upload_url": "https://<account>.r2.cloudflarestorage.com/hoard-sync-payloads/syncs/u42/<uuid>.csv?X-Amz-...",
  "key": "syncs/u42/<uuid>.csv",
  "expires_at": "2026-05-19T18:30:00Z"
}

Field	Type	Description
`upload_url`	string	Presigned R2 PUT URL. Send the CSV bytes, raw or gzipped, as the PUT body.
`key`	string	R2 object key. Echo this back in step 3. Matches `syncs/u<your_user_id>/<uuid>.csv`.
`expires_at`	string	ISO-8601 expiry (10 minutes from issue).

Error responses:

Code	Error code	Meaning
422	`invalid_product_line`	`product_line` is not configured for this account
503	`sync_paused`	New sync admission is paused for maintenance; honor the `Retry-After` header

Step 2: PUT the CSV to R2

The PUT goes to Cloudflare, not Hoard — no Authorization header required (the presigned URL is the auth). The PUT body may be either the raw CSV or a gzipped CSV. The object key keeps the .csv suffix either way; the server detects gzip by sniffing the 1f8b magic bytes when it reads the object. The presigned URL signs only the method, key, and expiry, so compressing needs no header or signature change. Current agent builds gzip the CSV before the PUT.

Step 3: Notify Hoard with the key

POST /api/v1/sync
Content-Type: application/json

Request body:

{"key": "syncs/u42/<uuid>.csv", "product_line": "Magic", "sync_cycle_id": "20260831-abc123"}

Field	Required	Description
`key`	Yes	The R2 key returned by step 1. Must be scoped to your user id.
`product_line`	No	Same semantics as the `X-Product-Line` header on the raw-CSV path.
`sync_cycle_id`	No	Stable client-generated identifier also sent to `/sync/log`. Current agents include it to avoid clock-skew and queue-order correlation races.

Response (HTTP 202):

{"status": "accepted"}

Error responses:

Code	Error code	Meaning
422	`invalid_r2_key`	`key` is missing or doesn’t match `syncs/u<your_user_id>/<uuid>.csv`
422	`invalid_product_line`	`product_line` is not configured for this account
503	`sync_paused`	New sync admission is paused for maintenance; honor the `Retry-After` header

curl example (V4 round trip)

# 1. Mint the presigned URL
RESP=$(curl -s -X POST https://www.tryhoard.com/api/v1/sync/upload-request \
  -H "Authorization: Bearer $HOARD_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"product_line":"Magic"}')
UPLOAD_URL=$(echo "$RESP" | jq -r .upload_url)
KEY=$(echo "$RESP" | jq -r .key)

# 2. PUT CSV straight to R2
curl -X PUT "$UPLOAD_URL" --data-binary @inventory.csv

# 3. Notify Hoard
curl -X POST https://www.tryhoard.com/api/v1/sync \
  -H "Authorization: Bearer $HOARD_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"key\":\"$KEY\",\"product_line\":\"Magic\"}"

Get price updates

Download a CSV of price changes to import back to TCGplayer.

GET /api/v1/export/price-updates

Returns a CSV string (text/csv), not JSON. If a price rollback is pending, the rollback CSV is served instead. Concurrent intake can finish while export waits; unpublished drafts remain excluded. A header-only CSV with no data rows is a normal 200 response, not an error. Treat it as “nothing to push”. It is returned when no updates are available, and also when:

The account has no paid entitlement (free tier).
The account has not granted TCGplayer write consent.
The account is past due on payment.
The account is in read-only (Watch Only) mode and an apply-price-updates task is already claimed and in flight.

Empty export reasons

A header-only 200 response includes X-Price-Export-Empty-Reason, with one or more comma-separated codes:

Code	Meaning
`not_entitled`, `consent_required`, `past_due`	Account permission, consent, or billing blocks export.
`tcgplayer_maintenance`	Marketplace maintenance blocks all export paths.
`read_only_claim_in_flight`	A price task was claimed before the account switched to Watch Only.
`read_only`	Automatic price delivery is disabled. Eligible manual CSV downloads remain available.
`repricing_paused`, `automation_paused`	Automatic repricing is paused. Ready rollbacks and eligible manual downloads remain available.
`price_mutation_in_progress`	Another price operation prevents automatic export.
`auto_push_hold`	The current batch requires seller approval.
`rows_unavailable`	Pushable rows exist but none could be claimed, because of an active export lease or a concurrent claim.
`no_pending_rows`	No export rows remain after eligibility filters.

The header is absent on nonempty CSV responses and 304 responses. A temporary block at task claim leaves price work pending; unrelated supported tasks remain claimable. Ready rollbacks and explicitly published Quick Add listings can still use a price task during automatic-pricing pauses, while automatic price rows remain held at export. Watch Only or loss of entitlement cancels pending price tasks.

Conditional GET (ETag)

When no rollback or Quick Add work is pending and the account is in read-only (Watch Only) sync mode, the response includes a weak ETag fingerprint of the underpriced-cards set. Clients that send If-None-Match: <last-etag> will receive 304 Not Modified if nothing has changed since the last pull — avoiding the CSV serialization roundtrip on idle polls. Rollback and Quick Add responses always return 200 because they carry side-effectful state transitions that must run on every poll. Auto-push accounts (sync_mode other than read_only) also always return 200 and never send an ETag, because the export claims a row lock on every call.

curl example

curl -H "Authorization: Bearer YOUR_API_KEY" \
  https://www.tryhoard.com/api/v1/export/price-updates \
  -o price-updates.csv

Request manual sync

Mark the account as having an explicit user-requested sync. The next poll on /api/v1/sync/pending returns action: "sync".

POST /api/v1/sync/request

Request body (optional):

{"kind": "pricing"}

Field	Required	Description
`kind`	No	Scope of the requested cycle, for example `full`, `pricing`, `orders`, or `refunds`. An unrecognized value is ignored rather than rejected, and the response reports `full`.

curl example

curl -X POST -H "Authorization: Bearer YOUR_API_KEY" \
  https://www.tryhoard.com/api/v1/sync/request

Response:

{"status": "requested", "kind": "full"}

Cooldown responses (402 and 429)

Two separate cooldown gates apply, depending on the account. When the per-account credits_metering_enabled flag is off (the default), accounts on a paid plan (including comp, founder, and active trials) always return 200. Free accounts inside the post-sync cooldown window return 429:

{
  "status": "cooldown",
  "cooldown_remaining_seconds": 878
}

The 429 body carries only status and cooldown_remaining_seconds. It has no balance and no top_up_path. When the flag is on AND the user is still within the post-sync cooldown window, the endpoint returns 402:

{
  "status": "cooldown",
  "cooldown_remaining_seconds": 878,
  "balance": 4,
  "top_up_path": "/billing/credit_packs"
}

The user can either wait the remaining seconds or call POST /api/v1/sync/skip_wait (below) to spend a credit and skip the wait.

Field	Type	Description
`status`	string	Always `"cooldown"` for this 402 branch.
`cooldown_remaining_seconds`	integer	Whole seconds until the next manual sync is allowed.
`balance`	integer	The user’s current credit balance.
`top_up_path`	string	Relative path to the top-up flow if the user wants to buy more credits.

Skip wait

Spend 1 credit to bypass the manual-sync cooldown. Wraps the Credits::SkipWaitCharge service which uses a FOR UPDATE row lock plus a reservation pattern so concurrent calls with the same idempotency key cannot double-charge.

POST /api/v1/sync/skip_wait
X-Idempotency-Key: <UUID>

This endpoint is independent of credits_metering_enabled — calling it IS the user’s explicit opt-in. A flag-OFF user with a balance can call it just fine; the gate is the balance, not the flag.

Headers

Header	Required	Description
`Authorization`	Yes	`Bearer YOUR_API_KEY`
`X-Idempotency-Key`	Yes	Caller-supplied idempotency key (UUID recommended). Replaying the same key returns the original transaction without a second charge.

curl example

curl -X POST \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "X-Idempotency-Key: f47ac10b-58cc-4372-a567-0e02b2c3d479" \
  https://www.tryhoard.com/api/v1/sync/skip_wait

Response (200, charged):

{
  "status": "charged",
  "balance": 4,
  "cooldown_remaining_seconds": 852,
  "transaction_id": 18
}

Success statuses (HTTP 200)

Status	Meaning
`charged`	First call — 1 credit deducted, sync requested. Returns the new `transaction_id`.
`replayed`	Same `X-Idempotency-Key` as a prior call. The original `transaction_id` is returned with no second charge.
`no_charge_needed`	User is already past cooldown — no charge taken.
`sync_in_flight`	A sync is already running; from the caller’s POV the effect is achieved. Only `status` is returned in this branch.

Error responses

Code	Status	Body	Meaning
400	—	`{ "error": "X-Idempotency-Key header is required", "code": "idempotency_key_required" }`	The `X-Idempotency-Key` header is missing or blank.
402	`insufficient_balance`	`{ "status": "insufficient_balance", "balance": 0, "top_up_path": "/billing/credit_packs" }`	User has 0 credits. Direct them to the top-up flow.
409	`mutex_held`	`{ "status": "mutex_held", "retry_after_seconds": 30 }`	A sync, rollback, or Preview Prices run is currently writing prices. Retry after `retry_after_seconds`.

Cancel sync

Request that an active sync stop safely.

POST /api/v1/sync/cancel

If the inventory worker holds a live mutation lease, cancellation is asynchronous. The server records the request, the worker stops at its next slab boundary, and only then releases the lease and clears sync_in_progress:

{"status": "cancel_requested"}

If no worker lease is active (for example, the agent is only holding its cool-down flag), the flag is cleared immediately and the response is {"status":"cancelled"}. Returns 409 with code: "no_sync_in_progress" if no sync is running. Stale agent state is also cleared automatically after 5 minutes.

Log sync cycle

Report the results of a completed sync cycle. Hoard sends this at the end of every cycle, whether it succeeded or failed.

POST /api/v1/sync/log
Content-Type: application/json

Request body:

{
  "status": "success",
  "sync_cycle_id": "20260506-abc123",
  "steps": [
    {"name": "login", "status": "success", "duration_ms": 1200},
    {"name": "export_inventory", "status": "success", "duration_ms": 8500},
    {"name": "upload_inventory", "status": "success", "duration_ms": 3200},
    {"name": "export_orders", "status": "failed", "error": "timeout waiting for download"}
  ],
  "agent_version": "0.4.9",
  "platform": "darwin/arm64",
  "duration_ms": 45000,
  "started_at": "2026-04-20T09:00:00Z"
}

Request fields

Field	Type	Required	Description
`status`	string	Yes	Overall result: `"success"`, `"partial"`, or `"failed"`
`sync_cycle_id`	string	No	Stable client-generated identifier for this sync cycle. Used to merge debug screenshots with the final step log.
`steps`	array	No	Each step with a `name`, `status`, optional `duration_ms`, and optional `error`
`agent_version`	string	No	The version of Hoard that ran this cycle
`platform`	string	No	Platform (e.g., `darwin/arm64`)
`duration_ms`	integer	No	Total cycle duration in milliseconds
`started_at`	string	No	ISO 8601 start time. Defaults to server time if omitted.

Response (HTTP 201): Empty body.

Upload debug screenshot

Send a Base64-encoded screenshot to the server when a sync step fails.

POST /api/v1/sync/debug
Content-Type: application/json

The screenshot must be Base64-encoded PNG and must not exceed 2 MB decoded. Include sync_cycle_id so the server can attach the screenshot to the correct cycle even if the final sync log has not arrived yet. Without sync_cycle_id, at least one existing sync log entry must exist. Request body:

{
  "sync_cycle_id": "20260506-abc123",
  "step_name": "login",
  "page_url": "https://store.tcgplayer.com/admin",
  "screenshot": "<base64-encoded PNG>",
  "captured_at": "2026-04-20T09:01:30Z"
}

Response (HTTP 201): Empty body. If sync_cycle_id is present and the final sync log has not arrived yet, the server creates a placeholder failed log row and updates that row when POST /api/v1/sync/log arrives with the same identifier. Error responses:

Code	Error code	Meaning
404	—	No sync log entry exists yet
413	`payload_too_large`	Screenshot exceeds 2 MB decoded

Member-owned additions

Quick Add contributions remain separate while staged. Publishing combines only permitted contributions with the same exact SKU into one additive CSV row. Conflicting requested prices require explicit recovery. Later additions cannot change a previously exported quantity and wait for its confirmation. A fresh inventory observation must reach the pre-export live quantity plus the sum of exported copies; the mere presence of an existing SKU is insufficient. Sales or external stock changes can prevent this conservative check from resolving, so keep the pending contribution visible and do not resubmit its copies. Generic repricing_events/failure calls do not requeue managed contributions, including when the price-decision ledger is disabled. Per-delivery human recovery supersedes only the affected delivery rows. An old token’s acceptance or failure callback ignores these rows and cannot change a newer attempt; unrelated manifest rows continue normally. Untokened legacy rejection callbacks cannot distinguish uploads, so they leave explicitly recovered contributions held for inventory reconciliation or further verified recovery. Explicitly recovered historical contributions are also excluded from untokened failure and timeout requeue. Once human recovery records evidence, only another verified resolution or inventory reconciliation may change their held outcome.

​Check pending

​curl example

​Response fields

​reason values

​Sync status

​curl example

​Response fields

​phase values

​Agent heartbeat

​Request fields

​Response fields

​Upload inventory

​Upload inventory (V4 presigned-URL flow)

​Step 1: Mint a presigned URL

​Step 2: PUT the CSV to R2

​Step 3: Notify Hoard with the key

​curl example (V4 round trip)

​Get price updates

​Empty export reasons

​Conditional GET (ETag)

​curl example

​Request manual sync

​curl example

​Cooldown responses (402 and 429)

​Skip wait

​Headers

​curl example

​Success statuses (HTTP 200)

​Error responses

​Cancel sync

​Log sync cycle

​Request fields

​Upload debug screenshot

​Member-owned additions

Check pending

curl example

Response fields

`reason` values

Sync status

curl example

Response fields

`phase` values

Agent heartbeat

Request fields

Response fields

Upload inventory

Upload inventory (V4 presigned-URL flow)

Step 1: Mint a presigned URL

Step 2: PUT the CSV to R2

Step 3: Notify Hoard with the key

curl example (V4 round trip)

Get price updates

Empty export reasons

Conditional GET (ETag)

curl example

Request manual sync

curl example

Cooldown responses (402 and 429)

Skip wait

Headers

curl example

Success statuses (HTTP 200)

Error responses

Cancel sync

Log sync cycle

Request fields

Upload debug screenshot

Member-owned additions