Vegetation Index (VI) Profile

This page shows you how to order and retrieve a Vegetation Index (VI) Profile — a season-long time series, rather than a downloadable map. See ANA Precision Farming APIs for the base URL, authentication, credit model, and general status codes — this page only covers what's specific to VI Profile.

This is not a map. Unlike the other four ANA products, a VI Profile doesn't produce a downloadable map image — it returns a time series of vegetation index values sampled across a growing season.

Endpoints

Method	Path	Purpose
POST	`profiles/vegetation-index-profile/orders/`	Create an order (single object only — no bulk)
GET	`profiles/vegetation-index-profile/orders/{ORDER_ID}/`	Retrieve an order
GET	`profiles/vegetation-index-profile/orders/`	List orders (supports query filters — see below)

Note the path prefix: profiles/, not maps/ like the other four ANA products.

Auth

Send your access token as a bearer token, as described in ANA Precision Farming APIs.

Required permission: vi-profile.create for create, vi-profile.view for list/retrieve.

Request fields

This endpoint does not inherit the shared field set from ANA Precision Farming APIs (field_boundary, output_data_type, no_of_classes, is_background). It only has:

Field	Type	Required	Notes
`field_uuid`	string	No (technically optional per schema, but effectively required in practice to identify the field)	Unlike every other ANA product, there is no `field_boundary` fallback — you must reference an existing field by UUID; you cannot submit a raw GeoJSON boundary instead.
`season_id`	integer	Yes	Identifies an existing Season (scoped to your company) whose `start_date`/`end_date` become the profile's time window — you don't supply dates directly.

There's no output_data_type, no_of_classes, or is_background here — those are map-rendering options and don't apply to a time-series product.

No bulk support

VI Profile does not support bulk ordering. Every create request is a single object.

List filtering

GET profiles/vegetation-index-profile/orders/ supports these query parameters:

Parameter	Matching
`company`	Exact
`created_by`	Exact
`index_code`	Partial match
`field`	Exact
`season`	Exact
`status`	Exact

Status codes specific to VI Profile

Status	Trigger
200	Order created.
400	Validation failure (for example, a missing `season_id`).
402	Insufficient wallet credit.
409	A profile for this exact field + season combination already exists and is active — see the dedup note below.
500	Internal error — including when the given `season_id` doesn't resolve to a real season for your company.

A duplicate VI Profile request (HTTP 409, below) doesn't cost extra credit. A field is only ever charged once — on its first successful ANA order, across any of the five products — and a request can only come back as a duplicate if an earlier order for that field already exists, meaning the charge already happened on that earlier order. See the credit model in ANA Maps Overview.

This dedup rule has no time window at all. Unlike every other ANA product, once a profile is active for a given field + season combination, it's permanently deduplicated — you'll never get a fresh profile for that same combination. The 409 response body includes the existing profile's UUID; treat it as success.

An HTTP 500 here can also mean your season_id didn't resolve to a real season for your company — the current implementation doesn't distinguish "bad input" from "processing failure" in this path, so it returns a generic internal-error response rather than a more specific 400 or 404. Double-check your season_id before reporting this as a platform issue.

Retrieve response

Instead of tif_url/application_map_url, a VI Profile's retrieve response includes:

Field	Notes
`profile`	The time-series array, fetched and merged in from storage at retrieve-time.
`status`	One of `pending`, `processing`, `active`, `failed`.
`index_code`	Defaults to `"NDVI"`.
`field`	The field this profile belongs to.
`season`	The season this profile belongs to.
`start_date` / `end_date`	Taken from the season, not user-supplied.

Freshness on retrieve. Retrieving a profile can silently trigger a background refresh if the data is more than a day old and the season hasn't ended yet. That means an immediate retrieve right after requesting new imagery may briefly show slightly stale data while the refresh catches up in the background.

Completion event

vi_profile_completed is published when a profile finishes processing. Unlike the four map products, this event does not carry a map_uuid — profiles have no map.

No persisted notification. Unlike the four map products, a completed VI Profile does not trigger a persisted in-app or email notification — only this real-time event is published. If your integration relies on notifications rather than listening for events or polling the retrieve endpoint, you won't be notified when a profile finishes.

Examples

Create an order

curl -X POST "https://backend.spacenus.de/api/v1.2/profiles/vegetation-index-profile/orders/" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "field_uuid": "FIELD_UUID",
    "season_id": 42
  }'

Response:

{
  "status": "success",
  "message": "VI Profile processing started successfully.",
  "data": {
    "order_id": 1187,
    "status": "processing"
  }
}

Retrieve an order

curl "https://backend.spacenus.de/api/v1.2/profiles/vegetation-index-profile/orders/ORDER_ID/" \
  -H "Authorization: Bearer YOUR_TOKEN"

Response:

{
  "status": "success",
  "message": "Request successful.",
  "data": {
    "order_id": 1187,
    "status": "active",
    "index_code": "NDVI",
    "field": 918,
    "season": 42,
    "start_date": "2026-03-01",
    "end_date": "2026-09-30",
    "profile": [
      {"date": "2026-03-05", "value": 0.31},
      {"date": "2026-03-20", "value": 0.44},
      {"date": "2026-04-04", "value": 0.58}
    ]
  }
}