get_job resolves a job in one call via GET /jobs/{id}

[gradill22]

The problem

get_job called GET /bulk/{job_id} purely to read kind off the response, then re-fetched GET /crawl/{job_id} for the fields the bulk shape omits (truncated, truncated_reason, per-item depth).

Two costs, both measured against the dev API:

1. A crawl-scoped key could not poll its own job. /bulk/* requires the bulk scope, and the discovery call 403s in middleware before the route runs. With scopes=["crawl"], GET /bulk/{id} → 403 while GET /jobs/{id} → 200.

2. Two back-to-back requests per crawl poll, with no spacing — fast enough to trip the API's own per-plan min-spacing limiter:

GET /bulk/{id}  -> 200
GET /crawl/{id} -> 429  rate_limit_too_fast   Retry-After-Ms: 38

The SDK was 429ing itself against our own API on a normal crawl poll.

The change

GET /jobs/{id} answers for either kind and requires neither scope. get_job and wait_for_job now issue exactly one request per poll and read kind off each body, on both the sync and async clients. wait_for_job drops its is_crawl routing — every iteration hits the same path.

This mirrors the JS SDK change so the two clients stay in step.

Verification

69 tests pass. The suite previously pinned the two-call behaviour, so those tests changed with it. The new ones assert the request path, not just the parsed result, so a regression back to /bulk + /crawl fails loudly rather than silently costing a round trip:

assert respx.calls.call_count == 1
assert respx.calls[0].request.url.path == f"/jobs/{job_id}"

The equivalent change was additionally confirmed end-to-end against a live local API through the JS client (same endpoint, same contract): one HTTP call for get_job and wait_for_job on a real crawl job, with kind, truncated, and per-item depth intact.

Deploy ordering

Requires the API change that adds /jobs/{id} to be deployed first (WellMarkedAPI/WellMarked#192). /bulk/{id} and /crawl/{id} are unchanged there, so already-released SDK versions keep working — but this version will 404 against an API that predates the endpoint. No fallback was added; happy to add one if you'd prefer.

Not verified here

The Python client wasn't exercised against the live dev API in this pass — its tests are respx-mocked, and the live end-to-end run went through the JS client against the same endpoint. Worth one live call before release.

Companion PR: JS-TS-SDK#12.

🤖 Generated with Claude Code