Cleans a batch of values — phone, email, address, company name, URL, job title, or person name — and returns the prepared results inline.

You choose the attribute, not the operations. Each attribute runs its own fixed set of default steps in a fixed order; a subset cannot be requested and the order cannot be changed. Any enrichment you request runs after those defaults complete, adding a stage rather than replacing one.

default steps -> Enrichment (optional, paid)

Six of the seven attributes run the same defaults: phone, email, person name, company name, URL and job title each parse, then validate, then normalize. Email applies typo correction as part of its normalize step.

Address is the exception and runs parse only. It has no validator — validating a free-text address is a different problem from validating a phone or an email, and address results carry no isValid at all. Address normalization is not a default either; it arrives one of two ways: with the VERIFICATION enrichment, or from config.normalizationRules if you supply custom rules. Those two are mutually exclusive.

Prepare works only on the values in the request. It does not look up, match, or append data from ZoomInfo, does not correct wrong values, and does not persist, route, or write back. To retrieve data you do not already have, use the Enrich endpoints.

Every request is single-typed. data.type selects the attribute and data.attributes.items carries values of that attribute only; mixed-attribute requests are not supported. Phone, email, address and person name accept either a raw string or a pre-structured components object, and each item supplies exactly one of the two. Company name, URL and job title are string-only and have no components alternative. The cap is 30 items per request.

Enrichments are passed once at the batch level, in data.attributes.enrichments, and apply to every item. Custom normalization is not an enrichment — request it through data.attributes.config.normalizationRules, as either inline rules or a saved configId, never both.

Results are positional. data is an array in 1:1 order with items, so data[i] is the result for items[i] and each resource's id is that index. The array is never reordered or filtered. Each element's type reports the outcome: a processed item is its attribute resource, carrying the echoed input, the parsed and normalized stage products, and the final value; an item that failed is a PrepareError resource carrying the failure detail. Items are processed independently, so a failed item still occupies its slot while the rest of the batch succeeds at 200.

isValid reports one thing: whether the input was in good enough shape to normalize and enrich. It is not a quality judgment — it does not mean the value is correct, deliverable, or safe. Deliverability comes only from VERIFICATION, safety only from THREAT. Address results omit isValid entirely; where any non-empty input is normalizable, such as job title, it is effectively always true.

Not every combination of enrichments and config is legal, and the illegal ones are rejected for the whole request. On an address request, supply exactly one of enrichments or config — VERIFICATION returns its own normalization along with deliverability and address type, so custom normalization cannot also apply, and supplying both or neither is rejected. On an email request, THREAT_TYPE requires THREAT on the same request. The legal type/value pairings for custom normalization are documented on each rule-value enum; values are scoped per attribute, so a value legal for one rule is not legal for every rule.

Only 200 returns results. Every other status returns an error document with no data array:

• 400 — nothing was processed. Causes: an empty items[]; more than 30 items; a body that does not parse; an unrecognized data.type; on an address request, both enrichments and config or neither; THREAT_TYPE requested without THREAT; both inline config.rules and a configId; a normalization-rule value not legal for its type. Do not retry unchanged.
• 402 — entitled to the work, but not enough credits to pay for it. Retry after topping up.
• 403 — refused for the account, not its content: either not enabled for credit-based billing, or missing the Data Quality entitlement for the requested work.
• 429 — rate limit exceeded. 25 requests per second, tenant-wide, shared across every Data Quality endpoint and caller in the tenant. Retry with exponential backoff and jitter.
• 5xx — server error (500) or unavailable dependency (503). Retry with backoff.

errors[].detail is diagnostic prose and may change; do not pattern-match it.

Parse, validate, and default normalize consume no credits. Each enrichment and custom normalization costs credits per result returned, and nothing is charged for a result that does not come back.

This operation is synchronous. There is no job queue, no polling, no webhook, and no cancel.