Working with Seasons 🌱

Overview

Seasons enable you to organize crop production into time-bounded cycles for comprehensive yield tracking and agronomic planning.

Cardinality summary

• Workspace ➜ 1..* Organizations
• Organization ➜ 1..* Seasons

Workspace
└── Organization
  └── Seasons 1..*

Key Concepts

API Documentation

For complete API reference including request/response schemas, authentication, and interactive testing, visit:

📚 Seasons API Documentation - Interactive API documentation with request/response examples

Available Endpoints

Best Practices

Business Rules

• Permission required: caller must have appropriate season create/update rights for the organization.
• Optional client-supplied id must be unused; existing ID causes rejection (no overwrite).
• name must be unique within the organization (case-insensitive) on both create and update.
• start_date must be strictly before end_date (validated on create and update).
• crop_id (if provided) must reference an existing crop.
• Changing crop_id is only allowed when no fields / crop zones are linked to the season.
• Season must exist for update operations.
• Persistence enforces uniqueness (duplicate id or name triggers conflict codes).
• Invalid date ordering immediately rejects the request (no partial persistence).
• Crop change guard prevents altering historical agronomic context inconsistently.

Error Codes

Detailed (non-exhaustive) errors for create and update flows.

Creation

Update

Next Steps

• Manage Crop Zones (Season × Field unique) →
• Fields Reference →
• Properties Reference →