Skip to main content
POST
Assess ESA and PULA requirements for one pesticide application.

​
Request

​
string
required
Your assigned provider identifier. It must match the API key.
​
string
required
Your customer account identifier.
​
string
required
Field name shown in the portal and compliance reports.
​
string
required
Your application identifier, unique within this provider and account. Resubmit this application to refresh its assessment.
​
string
required
Supported method: for example Broadcast-Ground, Broadcast-Air, Drone, or Airblast. Unsupported values return 422. Liberty Ultra is ground only.
​
string
required
A valid calendar date in YYYY-MM-DD format.
​
object
required
GeoJSON Feature containing a Polygon or MultiPolygon in EPSG:4326. Rings must be closed; self-intersections are rejected. Maximum 5,000 positions across the field boundary.
​
object[]
required
One to 100 product objects. See the product fields below.
​
string[]
required
Crop names. An explicit empty array is accepted.
​
string
Your field identifier, used for compliance report requests. If omitted or null, the application identifier is used.
​
string
Your work-order or job identifier. Optional for a single check; required for bulk submissions.
​
string[]
Default pests for products without their own pest list. Every product must have a nonempty effective pest list.
​
string
Optional applicator or grower email address; nullable.
​
number
Positive spray gallons per acre. Required to normalize rates expressed per 100 Gal or 100 Cu Ft; nullable.
​
string
ASABE category or code: EF, VF, F, M, C, VC, EC, or UC. Unsupported values return 422; nullable.
​
string
low or high for ground applications; nullable.

​
Product fields

​
Response options

See Understanding compliance determinations for runoff and drift scoring, setup violations, overall status, and when to refresh a result.
​
boolean
default:"false"
Include PULA field-boundary data when available.
​
boolean
default:"false"
Include analysis under compliance.soil.analysis when soil is available.
​
boolean
default:"false"
Include available options under compliance.mitigation_options.
​
number
default:"1"
PULA search buffer distance, clamped to 0–10 miles.

​
Response

success describes request handling. Read compliance.status, processing_complete, soil, runoff, drift, and issues for the assessment. compliance.scope is requirements_and_gaps; its version is the assessment format version, independent of the API URL version. Product results include esa_required, registration status, effective pests, and PULA limitations. For ESA-required checks, the response also includes an opaque application_event_id and a mitigation_portal_url when available. mitigation_portal_url_expires_at is the signed-link expiration in signed-link mode and null in token mode. expires_at describes the field portal’s availability, which can have a different lifetime. Use the returned link unchanged.

​
Product PULA limitations

products[] has one entry per submitted product, in request order. Each entry includes pulas[]: the PULAs intersecting the field that have active limitations for that product’s EPA number and the submitted application method. A product without matching limitations returns pulas: []. When no product requires ESA, the check returns early and every pulas array is empty. summary counts total_pulas (all PULAs intersecting the field, with or without product limitations), total_limitations, products_checked, and products_with_limitations. Any matching limitation adds the LIMITATIONS_REVIEW_REQUIRED issue, which keeps compliance.status indeterminate unless something is not_met. Runoff and drift requirements derived from a limitation are scored automatically; other conditions in the limitation text are not. Show the limitation text to the applicator. Completed bulk items return the same products and summary under result. Application compliance and group compliance return the saved product limitations under compliance.last_assessment.products.

​
Runoff requirements and portal exemptions

When a product or PULA introduces an EPA runoff requirement, the API assumes runoff is required immediately. No portal questionnaire answer is needed to evaluate points: sufficient credits return met, a shortfall returns not_met, and missing scoring inputs return indeterminate. Each compliance.runoff[] entry includes required, exempt, required_points, label_required_points, earned_points, gap, status, credited_measures, runoff_exemption_claimed_at, and runoff_exemption_reasons.
  • With no exemption, required: true, exempt: false, and required_points equals the label/PULA point target in label_required_points.
  • When the user saves an EPA runoff exemption in the portal, that application’s runoff returns status: "met", required: false, exempt: true, required_points: 0, and gap: 0. label_required_points retains the original target (or null if unresolved); earned credits and the saved exemption timestamp/reasons remain visible. Missing soil or an unresolved point target does not block an exempt runoff obligation.
  • Choosing “None apply” in the portal restores the point requirement. Rechecking the same application preserves its portal selection. A new application starts required, even on the same field.
  • Older required: false records without an exemption evaluation timestamp are treated as required. Timestamped legacy exemption selections without reason codes are honored.
Exemptions apply to EPA runoff only. Enlist, other runoff systems, drift, and PULA restrictions are still assessed separately, so a runoff exemption does not automatically make the entire application compliant. No request-body exemption flag is accepted; the portal records the user’s selection. These rules also apply to bulk checks. After a portal edit, use application compliance or group compliance for current runoff results. Previously returned checks and completed bulk results remain snapshots; resubmit a check to refresh its saved assessment.

​
Drift assessment

Single and bulk ESA checks identify drift requirements and reductions. They do not calculate application-time buffer placement or accept wind inputs. When a drift requirement exists and no known violation is found, intake drift remains indeterminate until you call compute application-time drift buffers with the application reference and current wind/setup. A known violation, such as droplets below the label minimum, returns drift and overall not_met immediately, even if other inputs remain unresolved. The application-time endpoint can return drift met with a remaining buffer: your supplied setup complies when spraying stays within the calculated treatable area. A 100% buffer reduction is not required. Its application_time.drift_status is separate from the overall application_time.status. Repeating an intake check produces a new intake assessment; recompute application-time drift afterward to assess placement for the new inputs.

​
Repeat a check

The provider/account/application identity is reused. Resubmitting updates the saved assessment when ESA processing is required. A no-ESA early return does not update an existing saved application. A changed field boundary refreshes its derived data. Background soil enrichment requires a new check to refresh the assessment. The example response below shows selected fields only; values depend on product, field, and review state.

​
Errors

Processing can return 409 DUPLICATE_FIELD, FIELD_OWNERSHIP_CONFLICT, DUPLICATE_APPLICATION, APPLICATION_FIELD_CONFLICT, PROCESSING_CONFLICT, FIELD_CHANGED, or APPLICATION_CHANGED. Signed portal setup can return 503 PORTAL_SAS_UNCONFIGURED. A workflow can also return 422 UNSUPPORTED_APPLICATION_METHOD; HTTP input validation normally catches this first as INVALID_REQUEST. See assessment issues for incomplete evidence returned with HTTP 200. 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.