Skip to main content
POST
Submit one job containing 1–100 field applications. Put values shared by your fields at the top of the request. Inside fields[], supply each field’s identity and boundary, plus any values that differ for that field. A field value replaces the matching top-level value for that field only. Other fields still use the top-level default. Products and crops follow the same rule: arrays replace the entire array; they never merge.

​
Request

​
string
Optional, strongly recommended. One to 200 characters. Scoped to your provider/account; reuse it only with identical effective inputs.
​
string
required
Your assigned provider, matching the key.
​
string
required
Your account identifier.
​
string
required
Required nonempty work-order/job identifier, up to 200 characters. Shared by every field.
​
object[]
required
One to 100 field entries. Each requires application_id, field_name, and field_boundary; provider_field_id is optional.
​
object[]
Default products; each field must have effective products.
​
string[]
Default crops; each field must have an effective crop array. An explicit empty array is valid.
​
string[]
Default pests, unless replaced by the field or product.
​
string
Default YYYY-MM-DD application date.
​
string
Default supported method.
​
number
Default positive spray gallons per acre; nullable.
​
string
Default supported droplet category/code; nullable.
​
string
Default low or high; nullable.
​
string
Default valid email; nullable.
​
boolean
default:"false"
Top-level response option applied to every field.
​
boolean
default:"false"
Top-level response option applied to every field.
​
boolean
default:"false"
Top-level response option applied to every field.
​
number
default:"1"
Top-level PULA search buffer, clamped to 0–10 miles.

​
Where each value belongs

You may omit all shared application settings and specify them separately in every field. You may also mix shared defaults and overrides in the same request. See single-check inputs for allowed methods, droplet sizes, product properties, and field boundary limits.

​
How defaults and overrides resolve

For each field, the API starts with the top-level defaults, replaces each property explicitly supplied by that field, then validates the resulting application independently. To change just one product’s rate, send the full desired product array for that field, including the other products you want retained. Each product needs its required properties (product_name, rate, and rate_unit); a partial product such as { "rate": 28 } is invalid.

​
Pest precedence

Pests have one additional level of precedence: product pest → field pest → top-level pest. Product pest lists stay attached to their product even when the product array is inherited. A field pest override affects only products without their own pest list. Every product must end up with a nonempty pest list.

​
Worked example

The complete cURL request on this page submits two fields using Liberty Ultra with Broadcast-Ground: North supplies no application-setting overrides, so every shared default applies. South supplies a complete replacement product array, replaces crop and gpa, and clears boom_height with null. South still inherits the date, method, pests, and droplet size. Clearing an application setting does not establish that it is irrelevant to compliance. Missing information can leave the assessment indeterminate.

​
Validation before acceptance

All fields are validated before the API accepts a job. One invalid field rejects the entire submission with 422 INVALID_REQUEST; no job is created. This differs from processing failures after acceptance, where some items can succeed and others fail.
  • Unknown top-level and field properties are rejected. For example, fields[0].include_geometry is invalid because that option belongs at the top level.
  • Supplied defaults must themselves be valid, even if every field overrides them. Omit an unused default instead of sending an invalid placeholder.
  • application_id values and effective provider_field_id values must be unique within the submission.
  • Each field boundary may contain at most 5,000 coordinate positions across all its rings. The total request body limit is 5 MB.
For example, a duplicate application ID on the second field returns:
Issue paths use zero-based array indexes, so fields[1] is the second field. Correct the indicated input and resubmit. See validation examples for missing group IDs, pests, and unknown properties.

​
Accepted response and polling

The response is 202 Accepted, including on an idempotent replay. It includes Location (the status path), Retry-After: 5, and Cache-Control: no-store. A replay can return an already-terminal job status. Both URLs are relative to the V2 hostname. Poll job status and fetch results. A job with some failed items can finish as completed_with_errors. A succeeded item can still contain an indeterminate or unmet compliance assessment.

​
Idempotency and retention

The same key and effective input return the existing job with replayed: true. Changing inputs returns 409 IDEMPOTENCY_CONFLICT. Without the header, each accepted submission creates a new job. Jobs and replay keys expire 30 days after completion; after expiration, the same key can create a new job. Split larger submissions into jobs of at most 100 fields. They may share provider_group_id, but each job needs its own idempotency key. A full backlog returns 429 BULK_BACKLOG_EXCEEDED.

​
Errors

Submission-specific errors are 409 IDEMPOTENCY_CONFLICT and 429 BULK_BACKLOG_EXCEEDED. Invalid defaults, overrides, duplicate identities, group IDs, or idempotency headers return 422 INVALID_REQUEST. No job is created for a validation error. All routes can also return authentication, validation, rate-limit, and dependency errors. Use the error catalog and examples to choose a retry or correction. Keep X-Request-ID when present.