The Spanish version is the authoritative reference. View in Spanish
GET /v1/documents/search
Endpoint of flow ③ — Gosocket periodically queries (polling) a document's status by its external_id until it obtains the processed XML and the original PDF, without depending on Docupath pushing the result via UploadZipDocument (Flow ②, which is only a manual contingency). This endpoint is the basis of the integration's automatic process.
Endpoint
https://api.docupathdev.app/v1/documents/searchhttps://api.docupath.app/v1/documents/searchMethod: GET · Authentication: Authorization: Bearer {access_token} → see POST /v1/oauth/token
Why does Gosocket consume this endpoint?
Flow ② (UploadZipDocument) depends on Docupath pushing the result once the document reaches approved status. In practice that transition requires manual review in the Docupath portal — the auto-approval ("autoreview") feature doesn't behave reliably, so the push either never happens or is delayed indefinitely. To avoid depending on that manual step, Gosocket queries this endpoint periodically until it obtains processed_info (processed XML) and file_url (original PDF).
Parameters
| Parameter | Type | Req. | Description |
|---|---|---|---|
external_id (query) | String | Required | The same external_id Gosocket generated and sent in POST /v1/documents |
Retry policy (polling)
Docupath doesn't support webhooks or automatic retries — the provider itself documents that retry responsibility falls on the integrating system. Gosocket implements polling with this policy:
| Parameter | Value |
|---|---|
| Interval between queries | 5 minutes |
| Maximum retries | 10 |
| Total wait window | ~50 minutes from when the document was sent (Flow ①) |
| Success condition | current_status is pending_review or approved with processed_info present in the response |
| Unsuccessful end condition | Retries exhausted with current_status at uploaded / processing, or the document moves to rejected / expired |
Tests against the DEV environment show that processed_info and file_url are already present at pending_review status — before anyone manually approves the document in the Docupath portal. This is what lets polling avoid Flow ②'s bottleneck: Gosocket doesn't need to wait for approved, only for processed_info to exist in the response.
Request / Response
GET {base_url}/v1/documents/search?external_id=0012-00003835
Authorization: Bearer {access_token}Response fields
| Field | Type | Description |
|---|---|---|
external_id | String | The same identifier sent in Flow ① |
current_status | String (enum) | See Possible states |
processed_timestamp | DateTime | null | Date when Docupath completed AI processing. In tests against DEV it was always observed as null, even at approved status — pending confirmation with Docupath on whether it's populated under a different configuration |
processed_info | String (XML) | Processed XML, in Gosocket native format — this is the data that satisfies the "obtain the processed XML" criterion. Present from pending_review onward |
file_url | String (signed URL) | URL to the original PDF — satisfies "obtain the original PDF". It's a signed URL with an expiration (Expires, Signature, Key-Pair-Id parameters); it must be downloaded immediately, and should not be persisted as a permanent reference |
Prior documentation for this integration recorded the field as document_url. Responses captured in direct tests against DEV return file_url. This page uses the name confirmed by direct testing; if a future integration receives document_url instead, verify with the Docupath team which name is current in that environment.
Possible states
| State | Description | processed_info / file_url available |
|---|---|---|
uploaded | Document received, pending processing | No |
processing | The AI is extracting and validating the data | No |
pending_review | Processed — pending manual review in the Docupath portal | Yes |
approved | Manual review completed | Yes |
rejected | Rejected — doesn't meet the configured validation rules | No |
expired | The document expired without being processed | No |
Error catalog
| HTTP | Cause | Resolution |
|---|---|---|
| 401 | Expired or invalid token | Request a new access_token via POST /v1/oauth/token |
The behavior when external_id doesn't exist (404 vs. empty data) hasn't been confirmed, nor has /v1/documents/search behavior in the PRD environment. Update this table once confirmed by testing.