Skip to main content
This example describes an integration that tracks every SOV processed or updated in Ping.Extraction. The workflow described polls a single cursor-paginated endpoint which supplies all completed or failed items. This workflow only observes activity. To submit parsing jobs and updates from the same loop that tracks them, see Build an SOV Pipeline. This cursor-based approach is preferred over callbacks, because:
  • the client system doesn’t need to expose any endpoints to the public internet.
  • authentication is one-way
  • if a problem or outage occurs on either side, recovering the lost messages is simple: just back the cursor up and reprocess the missed section as desired.
  • the client only needs to poll a single endpoint, at any desired frequency (5 seconds or 5 days!), rather than tracking multiple in-flight requests to observe transactional status
The code blocks let you choose between Python and cURL. A runnable Python script is available for download at the bottom of the page. Try filling in the blanks (e.g., {id}) to go through the workflow using cURL. This workflow demonstrates how to:

1. Poll List Historical SOVs

Poll List Historical SOVs to retrieve a chronological list of SOVs and SUDs processed by the system. The endpoint is cursor-paginated: pass the cursor_id returned by the previous response to fetch only records added since the last poll. Treat the cursor as opaque — pass it through unchanged rather than parsing it. Save each returned id if you plan to fetch full details in step 2. Each result includes a record_type. ORIG indicates a newly parsed SOV. Any other value indicates a later revision (an SUD). The accompanying revision field is 0 for the original record and increments with each update. status uses single-letter codes: C for complete and F for failed. Example code:
monitor_sov_activity.py
Example response:
JSON output

2. Get Historical SOV Details

From inside the step 1 loop, call Get Historical SOV with a record’s id to retrieve its full processing details. The payload is wrapped under result and includes the source filename, row count, submission metadata, lineage fields (original_sovid and previous_sovid for tracing SUDs back to their parent SOV), and an outputs[] array with a download URL for each generated artifact. The demo script calls this for failed records (status F) to surface the error_message. E.g., https://api.sovfixer.com/api/v1/sov/history/s-lo-ping-fd2acv Example code:
monitor_sov_activity.py
Example response:
JSON output

Python Demo

A minimal runnable script that polls the history endpoint and prints each new SOV and SUD as it appears. Set SOVFIXER_AUTH_TOKEN and run with python monitor_sov_activity.py.                                  Download Python Script here
monitor_sov_activity.py