2026 API client checklist from three open specs, and where Sume stands

A 2026 API client needs three habits that three public specs describe: read rate-limit headers instead of guessing, send an idempotency key on every unsafe retry, and verify signed webhooks against the raw body. Sume supports the intent of all three but not the exact wire formats, so write the client against Sume's documented headers.

None of the three specs is a finished standard this week. The RateLimit header draft is still an Internet-Draft, the Idempotency-Key draft has expired, and Standard Webhooks is a community specification, so copying a header name from one of them into a Sume client will not work.

What each spec says, and what Sume does

The first three columns come from the vendor pages linked in the sources (read 2026-10-03). The last column is from Sume's errors and rate limits and webhooks pages.

What this means in code

Rate limits: read ratelimit-remaining instead of counting requests, back off on retry-after, and note that a 429 names its bucket in error.details.scope, either read or write. Reads and writes have separate budgets, so a poll loop cannot 429 your submits; the numbers are in the per-plan table.

Idempotency: generate the key once per business intent, persist it before the first attempt and reuse it for every retry. Reuse a key only for the same payload, because a changed body is a conflict, not a replay. Deriving the key from a business key and a payload hash shows one way.

Webhooks: verify the HMAC over <timestamp>.<raw_body>, reject stale timestamps, accept any one entry of the signature header, and dedupe on the id field named above. If you later add a Standard Webhooks provider, keep the verifiers separate, because the header names, the signed string and the encoding all differ.