Get a Contact Profile Refresh Request

Looks up a refresh request by the unique_identifier returned at create time and returns the request envelope with every profile of the request, in its current state. This is the recommended way to get the results: it always returns every profile of the request. A webhook is only an optional completion signal.

Response formats

• Full (default) — the request envelope plus contact_profile_refreshes: a flat array of { custom_columns, contact_data } for a synchronous request, or { total, page_no, page_size, profiles } for an asynchronous one.
• response_format=summary — { request_id, status, unique_identifier } only. The smallest response for checking whether the request is done.
• response_format=changes — the status fields plus a compact profiles collection carrying the ds_* change-detection fields (primary position, baseline, verdict booleans, change types and events) instead of the full contact_data. Use it for job-change monitoring.

Any other value of response_format returns the full format.

Pagination

page_no and page_size apply only to asynchronous requests (synchronous: false at creation); a synchronous request always returns every profile as a flat array. Defaults are 1 and 50; both must be 1 or greater. The wrapper echoes the values you sent (a query-string value comes back as a string).

Change verdicts

changed_company / changed_title (full format, webhook) and the ds_* fields (changes format) answer one question: did the contact’s primary position change compared with your account’s previous refresh of this contact? The verdict has no look-back window: contact_refresh_time doesn’t limit how far back the comparison reaches; it controls which contacts get refreshed. The first refresh of a contact for your account has no baseline and reports false / false. If the contact already had positions, ds_change_status is undetermined with reason no prior snapshot; if this refresh delivered the contact’s first positions, both change types are newly_added (no_change when those positions have all already ended). Either way it establishes the baseline, and the second refresh is the first that can report a change. The verdict is computed once, when the refresh concludes for that profile — the profile can still be in progress while requested contact details are fetched — and does not change afterwards.

Repeated polling

Polling has no fee of its own. Once status is completed, stop polling: if you set a webhook, further calls can trigger additional deliveries to it, so make your webhook receiver idempotent. A valid unique_identifier keeps working after the request has completed.