Skip to content

Archive Consumption (V1 to V2)

This section explains how V1 archive consumption is reflected in V2 so usage and reporting remain consistent.

V1 behavior recap

In V1, archive imagery is consumed tile by tile through the API or web.

How V2 represents V1 archive consumption

To reflect that usage in V2, the system creates a monthly order for each capture and processing level combination:

  • One order per capture + processing level per month.
  • Each downloaded tile becomes one deliverable in that monthly order.
  • If the same tile is downloaded multiple times in the same month, it is counted once.
  • If the same tile is downloaded in a different month, it becomes a new deliverable for that month.
  • These orders remain IN_PROGRESS until month end, then move to CLOSED.

Product used for this accounting:

  • Product name: Direct download from Archive
  • SKU: ARCLGD-M.NN.NN

Example (simplified)

  • February: You download 10 tiles from capture A at L1C.
  • V2 creates one order for capture A + L1C (February).
  • The order shows 10 deliverables.
  • You download 3 of the same tiles again in February.
  • Deliverables count stays 10.
  • March: You download 2 tiles from the same capture at L1C.
  • V2 creates a new monthly order for March with 2 deliverables.

Why this model exists

This approach preserves V1 tile-based accounting while aligning with the V2 order, capture, and deliverable model.

For V1 users migrating to V2 API

If you were using V1 Archive API to download tiles, you can now:

  • Use V2 Orders API to order any processing level (regardless of the imediate availability of that processing level in the archive)
  • Get automatic clipping and stitching
  • Track orders with full event history

See Adopting Aleph V2 − Archive workflow migration for the side-by-side workflow comparison.