Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mayatech.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

​
Why idempotency keys?

Network failures and timeouts can leave you uncertain whether a POST succeeded. If you retry a generation request and the original call had actually completed, you’d be charged twice. Idempotency keys let you safely retry: the same key + same body returns the original response, never a second one.

​
How to use

Pass an Idempotency-Key header on POST /v1/images and POST /v1/videos. Use any opaque value, 1 to 256 characters. UUID v4 is recommended. 
curl -X POST https://api.aurous-labs.com/v1/images \
  -H "X-Api-Key: $AUROUS_API_KEY" \
  -H "Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000" \
  -H "Content-Type: application/json" \
  -d '{"prompt": "a sunset over mountains", "count": 1}'
If you retry with the same key and the same body, the original response is replayed: 
HTTP/1.1 201 Created
Aurous-Idempotent-Replayed: true

​
Rules

ScenarioBehavior
Same key, same bodyReplay cached response with Aurous-Idempotent-Replayed: true
Same key, different body409 idempotency_key_in_use
New keyProcess normally, cache for 24 hours
Header omittedProcess normally; never replays

​
Caveats

  • Keys are scoped per team — collisions across teams are impossible.
  • Keys expire after 24 hours. After that, the same key starts fresh.
  • Body comparison uses canonical JSON (lexicographic key order). {"a":1,"b":2} and {"b":2,"a":1} are treated as identical.
  • The header is optional; absent header behaves like a fresh non-idempotent request every time.