Social search returned 202 after 30 s: follow the job, don't resend

When a /v1/scrapecreators/* call is still running after 30 seconds, Sume answers 202 with the job instead of timing out your client. Keep the job, poll it, and do not resend the body: a resend asks the upstream network again and spends vendor credits a second time.

A 200 means the job reached a terminal state inside the sync wait and data.result already holds the answer. Your client needs to accept both codes as success.

What the two responses carry

Both shapes use the same envelope: data.operation, data.request_id, data.job, data.result and data.idempotency_hit. On 202 the job is the thing to follow and result is not yet final.

The OpenAPI text says to continue with jobs_wait then jobs_result using the request_id. Those are the MCP tools. Over plain HTTP you use the job endpoints described in Jobs and results: GET /v1/jobs/:id/status until it is terminal, then GET /v1/jobs/:id/result.

Idempotency and retries

idempotency_hit in the envelope tells you the response came from an earlier request with the same key. Send an Idempotency-Key header on calls you might repeat after a network failure, so a client crash between submit and receive does not run the read twice.

The 403 row applies to service-account keys only. A key whose allowed operations do not include scrapecreators.read cannot call any of the 15 routes.

A client rule that fits all of it

Treat 200 and 202 as the same success path, branch on whether result is terminal, and put a total deadline of a few minutes on the poll loop. Because these reads are not billed by Sume in v1, the cost of a bug here is vendor credits and latency, not your balance, which is a good reason to find it in testing instead of production.