Skip to main content

Idempotent Requests with The Hog API

Pass the Idempotency-Key header on async POST requests to safely retry without creating duplicate jobs. The key is scoped to your organization.
Network errors and timeouts are a normal part of distributed systems. When you fire off an async request to The Hog and the connection drops before you receive a response, you can’t be sure whether the job was created or not. Retrying blindly risks submitting the same job twice — consuming double the credits and producing duplicate results. Idempotency keys solve this by letting The Hog recognize a repeated request and return the existing job instead of creating a new one.

Supported endpoints

Idempotency keys are accepted on these async POST endpoints:

How to use it

Include the Idempotency-Key header with a unique string value in your POST request. A UUID v4 is the recommended format.
If the request was already received with the same key, The Hog returns the existing operation — same operationId, same pollUrl — without creating a new job or charging additional credits.

Key scope

Idempotency keys are scoped per organization. Two different organizations that happen to use the same key value are treated as completely independent requests — there is no cross-organization interference.

When to use idempotency keys

Network timeouts

If a request times out before you receive a response, retry with the same key. You’ll get back the existing job if it was received, or a new one if it wasn’t.

5xx retries

After a 500 or 503 error, retry with the same key. The Hog will not create a duplicate job if the first request was successfully enqueued before the error occurred.

Uncertain delivery

Any time you’re unsure whether a request arrived — load balancer resets, client crashes — include a key and retry freely.

At-least-once delivery

If your worker system guarantees at-least-once delivery, use a stable key derived from your own job ID to make The Hog calls naturally idempotent.

Choosing a key

Generate a UUID v4 fresh for each logical request. Do not reuse a key across different requests that should produce different results.
A key is only meaningful within your organization’s scope. Generate a new key for each distinct logical job — if you reuse the same key for genuinely different requests, the second request will return the result of the first one.