Common terms
| Term | Meaning |
|---|---|
| SOV | Statement of Values. A spreadsheet listing insured locations and buildings with their values, construction details, and policy information. This is the input document you upload. |
| Ping SOV | The normalized SOV that Ping produces from your source workbook. Every source workbook, regardless of its original layout, becomes the same structured representation, available in any enabled output format. Outputs carry the label Ping SOV in responses unless the format defines a more specific label. |
| SUD | SOV Update Data. A revision applied to an existing SOV, carrying its own ID derived from the parent SOV ID. See How SUDs work. |
revision | Integer counting updates to an SOV. 0 is the original parse. Each SUD increments it. |
record_type | Distinguishes records in List Historical SOVs. ORIG is a newly parsed SOV. Any other value (for example SCRUB or API) is a SUD. |
output_format | A file format generated from the Ping SOV, such as JSON or AUDITOR. Allowed values are gated by organization. Requests are case-insensitive. Discover the formats your account can use, and their canonical identifiers, with List Available Output Formats. See Output Formats for the full reference. |
| Output | A generated file for one SOV or SUD in one format. Each output has a filename and a url you download with your API token. |
| Integrations | Datasource codes, such as PG (Ping Geocoding) or PH (Ping Hazard), that enrich buildings with third-party data at parse or update time. Codes come from Ping.Data’s List Datasources. See Data Integrations for the attributes each source adds. |
| Job | An asynchronous unit of work, such as a parse, an update, or an output generation. Start it with a POST, then poll its status endpoint until request.status is COMPLETE or FAILED. |
Identifiers
Several identifiers move between requests as you work with the API. All of them are strings. Unless the shape is documented below, treat the value as opaque — store it and pass it back unchanged.| Identifier | Example | Where you get it | Where you use it |
|---|---|---|---|
SOV ID (sovid) | s-pl-ping-21nyms3 | Returned by Start SOV Parsing Job | Status checks, output downloads, update jobs, and history lookups for that SOV. |
SUD ID (sudid) | s-pl-ping-21nyms3-r001 | Returned by Initiate SOV Update Job | Update status checks and output requests for that revision. Shape is the parent SOV ID plus -r and the zero-padded revision number. |
Ping ID (pingid) | p-mk-tempo-esw5ab | Returned by Ping.Vision’s Initiate New Submission | Ping.Vision submission endpoints and events. Present on Extraction history records when a submission is involved. |
item_key | i-s-pl-ping-21nyms3!Sheet1!7 | buildings[].item_key in a JSON output | Identifies one building in an update CSV. Copy it verbatim from the output. |
| Output request ID | 9f4d8c10-3b7e-4a52-bd91-c823f15e4d76 | request.id in the Get Or Create SOV Output response | Polling Get/Check SOV Output Result. Cached responses carry an immediately-done- prefix. Use request.status, not the prefix, to detect completion. |
cursor_id | — | List endpoints such as List Historical SOVs | Pass it back unchanged to fetch the next page. |
client_ref | your own value | You choose it | Supplied when starting a parse or update job, returned on history records. |
client_ref is the one identifier you pick yourself. Pass a reference your system
can map back, such as your own submission key, when calling
Start SOV Parsing Job or
Initiate SOV Update Job.
List Historical SOVs returns it
on every record, which makes it the supported way to reconcile Ping activity against
your own records without storing a mapping of Ping IDs on your side.