Limits and Safeguards

These controls protect request quality, customer isolation and service capacity. Design integrations to handle a rejected request, a partial batch and temporary backpressure as normal, distinct outcomes.

Request Limits

Read limits.synchronous_batch_rows and limits.asynchronous_job_rows from release metadata. Use the lowest applicable release, plan and payload limit. Jobs provide durable processing, not an exemption from request-size limits.

Standard and Development Deadlines

The following controls apply to synchronous standard and development routes, including their batch endpoints:

The processing deadline is not a promise that a client will receive the full response within 25 seconds. Network transfer time is additional. These specific processing and response-size controls should not be assumed to describe the simple routes.

Split a batch or request fewer comparables if its response is too large. If a workload cannot reliably complete synchronously, submit a valuation job. A timeout does not prove that processing stopped or that no quota was consumed. Do not immediately repeat a timed-out batch in parallel.

Rate, Quota and Capacity Controls

Request rate, burst, monthly allowances and concurrent-request limits depend on the account plan. A row counts as a valuation unit; putting 2,500 rows in one request does not turn them into one valuation unit.

The API also limits admitted work when serving capacity is occupied. A valid key and unused quota do not guarantee immediate admission. Handle temporary 429 or 503 responses with bounded backoff and the returned Retry-After. Start with serial batches and increase concurrency only within the agreed plan. Avoid launching many maximum-size batches simultaneously.

A depleted monthly allowance is not a transient fault. Do not retry monthly_valuation_quota_exceeded until the allowance resets or the plan changes.

Input and Identity Checks

Unknown fields and unsupported values are rejected. Existing-property requests must identify one exact property: a supplied UPRN is checked against the address, and a missing UPRN must be resolved before valuation. A coverage response does not bypass these identity checks.

Development requests instead require the site's postcode and WGS84 coordinates. The endpoint applies a fixed new-build specification. Do not submit UPRNs, stored-data options, fabric settings or a construction-age band to these routes. See Development Valuations for the complete schema.

Leasehold properties require valid lease details. Property-form rules and market-domain checks also apply. A structurally valid property can be referred without an estimate when it falls outside the supported automated market.

Batch and Job Safety

Batch results preserve request order. HTTP 200 does not mean every property was valued: inspect each row's status and the batch summary. Invalid shared options or an invalid envelope can reject the entire request; row-specific failures are returned against the affected property.

Jobs are isolated to the submitting tenant and retain their submitted release. Use an idempotency_key when submitting work. Retry an uncertain submission with the same key and identical body; a different body with the same key returns 409. A request_reference is only a customer reference and does not make a synchronous request idempotent.

HTTP 202 means accepted or not yet complete, not valued. Poll the returned status URL with backoff. If results are not ready, honour Retry-After: 5. Download completed results before their expiry.

Evidence and Response Handling

Simple responses omit optional comparables and context. Standard and development responses can include them, but the requested comparable count is a maximum, not a guarantee. A successful valuation can have no displayed comparables. Feature attribution is not an option on customer valuation endpoints.

Keep execution_id, valuation_id, release_id and your request reference with the response. Do not log API keys. Follow Errors and Retries for outcome-specific recovery and Latency and Throughput when choosing batch sizes.