Authentication

Every request requires a Valtaic API key associated with an active customer account and authorised for the requested operation.

Credential Safety

Store keys in a server-side secret manager.
Never embed a live key in browser or mobile application code.
Redact authentication headers from logs and error tracking.
Use separate credentials for development, staging and production.
Issue separate keys to independent systems.
Rotate immediately after suspected exposure.

Do not expose a live key in browser or mobile code. Route client requests through a trusted backend, which then calls Valtaic.

Environments

Keys carry an environment prefix:

text

vlt_live_...
vlt_test_...

The assigned plan and scopes remain authoritative. A vlt_test_ prefix does not, by itself, select a free sandbox or different service. Use the environment and usage terms agreed for your account.

Scopes

Scope	Access
`avm:value`	Existing-property valuation, batch, metadata and enabled job endpoints
`avm:development`	Individual and batch development-valuation endpoints
`avm:stored-data`	Permission to set `options.use_stored_data=true` on supported endpoints

Submitting a development job requires both avm:value and avm:development. The dedicated synchronous development routes require avm:development.

Effective access is limited by both the key and its associated plan. A request outside those permissions returns 403 insufficient_scope.

The presence of a scope does not enable a capability that is absent from GET /v3/releases/current.

Plan Controls

A plan can define:

request rate and burst;
HTTP requests per month;
valuation units per month;
maximum synchronous batch rows;
maximum asynchronous job rows;
maximum concurrent in-flight requests;
available scopes.

A valuation unit is one property row:

Call	Units
Single value	1
500-row batch	500
2,500-row job	2,500

The service supports up to 2,500 synchronous rows or 2,500 job rows. Read the active limits from GET /v3/releases/current; your plan and the request-body limit may impose lower limits. Retrying an identical job with the same valid idempotency_key does not reserve its valuation units again.

Authorisation and Limits

Before processing a request, Valtaic validates the key, confirms that its plan is active and checks the required scope. Rate, quota, batch-size and concurrency limits are then applied according to that plan. See Limits and Safeguards for payload, capacity and processing controls that apply alongside plan limits.

Authentication and Limit Errors

Status	Condition	Action
`401`	Missing or invalid key	Supply an active credential.
`403`	`insufficient_scope`	Use an authorised key/plan.
`413`	`plan_batch_limit_exceeded`	Split work or use an approved larger limit.
`429`	`monthly_valuation_quota_exceeded`	Wait for reset or change plan.
`429`	`tenant_concurrency_limit_exceeded`	Respect `Retry-After` and retry with jitter.
`503`	Authentication or request admission temporarily unavailable	Retry with bounded backoff.

Zero-Downtime Rotation

Issue a second key for the same tenant and plan.
Store it in the consuming system's secret manager.
Deploy the consuming system with the replacement.
Confirm successful usage.
Revoke the old key.