Concepts & Identifiers

This page defines the terms and identifiers that recur across the Ping APIs. For how these fit together when processing a document, see How Ping Processes SOVs.

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.
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. Outputs serve different purposes depending on the format. See Outputter types.
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`.

Outputter types

Ping produces many output formats, and your organization may have its own configured beyond the public set. The formats your account can request, with their canonical identifiers and labels, come from List Available Output Formats. See Output Formats for the public reference. The categories below group those formats by what they are for.

Type	What it produces	Use it for
Computer-readable formats	Structured data for machine consumption: JSON, account and location files for catastrophe models such as AIR and RMS, and alternative encodings.	Feeding SOV data into your own systems. This is the primary path for integrations.
Scrubbers	Macro-enabled Excel workbooks (`.xlsm`) for reviewing and correcting the structured data Ping extracts.	Hands-on data entry and correction. A working artifact for getting the SOV right, not a final deliverable.
Modelers	Macro-enabled Excel workbooks (`.xlsm`) that update an SOV in place at the account and location level and run catastrophe tasks.	Brokers and underwriters adjusting already-extracted data, rather than first-pass correction.
Auditor	A read-only Excel workbook (`.xlsx`, no macros) with a summary view of the parsed data.	Reviewing scrubbing decisions without changing them.
Marketing SOVs	Presentation-ready Excel workbooks (`.xlsx`, no macros) in a co-branded layout with an organization’s colors and preferences.	Sharing an SOV externally in a polished format.
Partner import formats	Exports that reshape Ping’s data into the layout another system expects.	Handing SOV data to a carrier or downstream platform for direct import.
Other	Additional formats such as PowerPoint summaries and partner-specific CSV layouts.	Specialized delivery needs outside the categories above.

Most of these formats, including organization-specific workbooks and partner exports, are configured per account. Call List Available Output Formats to see the complete set you can request.

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.

Overview

Ping.Extraction

Ping.Data

Ping.Vision

Common terms

Outputter types

Identifiers

​Common terms

​Outputter types

​Identifiers

Common terms

Outputter types

Identifiers