Skip to main content

Request Limits

Purpose​

Use this page to design stable request throughput so integrations remain reliable under concurrency.

Limit values vary by endpoint class, plan tier, and current account context. Treat OpenAPI and runtime responses as authoritative.

Before You Start​

  • Confirm you are using the canonical base URL and headers from Authentication.
  • Review Error codes for status handling rules.
  • Use API reference and OpenAPI for canonical limits/contracts, then apply workflow handling in task guides.

Minimal Request Example​

Use this pattern when a burst request receives 429 and should be retried safely:

curl -X POST "https://api.clearsky.vision/api/tasking/orders/estimate" \
  -H "x-api-key: $CLEARSKY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "Wkt": "POLYGON((9.87 56.47,10.19 56.47,10.19 56.28,9.87 56.28,9.87 56.47))",
    "SatelliteConstellations": ["Sentinel1", "Sentinel2", "Landsat89"],
    "Model": "Stratus2",
    "StorageMonths": 1,
    "ApiRequests": 1,
    "ImageFrequency": 3,
    "ReferenceDate": "2025-01-01",
    "From": "2025-04-01",
    "To": null
  }'

On 429, back off and retry rather than hammering the same request.

Common Failure and Fix​

  • Failure: high parallelism causes repeated 429 and queue collapse.
  • Fix:
    • reduce concurrent workers,
    • add exponential backoff + jitter,
    • split very large jobs into smaller units.

Recommended status handling baseline:

  • Retry 429 and 5xx with exponential backoff and jitter.
  • Do not blindly retry 400; fix the request payload first.
  • For 401/403, verify key validity, scope, and account context.

Next Step​