Skip to content

🚀 Orders API Adoption Guide

Why evolve to the Orders API?

We acknowledged our previous API ecosystem had limitations, which the new Orders API addresses:

Product-Specific Design Constraints

  • The Tasking API was optimized for tasking workflows, which worked well for those use cases but didn't extend naturally to Archive products
  • Archive workflow was fragmented, as it used STAC API for discovery and downlowd (limited to available processing levels), with web-based-only ordering of different processing levels. There was no order tracking, and delivery followed did not support our standard delivery methods

State Tracking Limitations

  • Task and captures states covered the basic needs, but some use cases remained unclear
  • Multi-deliverable captures (e.g., L1B and L1D from a single capture) could only track one deliverable's status in the task-capture representation
  • Some failure states provided limited context about what progress was achieved or the specific reason for failure

Growing Integration Complexity

  • Multiple specialized APIs (Analysis, Tasking, Archive, Delivery) each optimized for their domain, using slightly different entities and language
  • Increasing complexity for users who needed to work across multiple product types

The Orders API Evolution

The Orders API builds on the strengths of our previous systems while addressing these pain points:

  • Unified Interface: Single API that maintains the specialized capabilities while providing consistent patterns
  • Enhanced State Clarity: Simplified order states with detailed tracking through sub-entities states and events
  • Complete Product Support: Native support for all current and future product types, using our standard product names and SKUs
  • Multi-deliverable Tracking: Proper representation of multi capture-to-deliverable relationships
  • Improved Diagnostics: Specific events and states that provide clearer context for any issues

Adoption Strategy

You can start benefiting from the Orders API without changing all your existing workflows. This guide shows you how to gradually adopt new capabilities while maintaining your current operations.

Orders are automatically created in representation for your existing and new Tasks and Archive consumptions, so we suggest you start with a "read-only" tracking / monitoring approach: While you may place request and consume our data using your regular workflows, you may start leveraging the new orders representation to answer some operational necessities.

Obtain details about a specific task or archive order

Which are all my orders?

How do I monitor my legacy tasks via Orders API?

  • Which is the order for my task with {task_id}?

GET /orders?task_id={task_id}

  • Which is the order for my task with {task_name}?

GET /orders?order_name={task_name}

  • Which orders are in status in_progress?

GET /orders?status=in_progress

  • Which orders had their status changed since date_time (date_time may be: my last query, my last login, etc)?

GET /orders?updated_at__gte="2025-08-26T17:29:05.952792Z"

Query orders by task_id to track your tasks in the new representation: * Get orders/{task_id}

Monitor your past consumptions using the deliverables endpoint

Data consumption within some period of time is directly linked to delivered quantities within that period of time. The deiverables endpoint is specifically designed to query deliverables and apply filters, both to track status and to compute billable quantities to achieve transparent consumption and billing.

Check Archive orders

Get products con los SKUs que tiene asignados el contrato Archivo Rush o Archivo Standard Tasking