Reading job output
After a job is submitted and started, it will transition through multiple lifecycle states.
It is possible to receive a notification when a job is done or poll the status.
After a job is completed, the output can be downloaded. The output consists of the result set and an error report.
Any response from backend service with a success response code and some data will be added to the result.
All issues with parsing the input or backend service response with error (4xx or 5xx) will be added to an error report.
An exception is a 404 - Not Found response, which is handled like an empty response (applies only to lookup service).
The content of the result is defined at job creation time. After a job is completed, neither format nor content of the result can be changed. A new job has to be submitted in this case.
Results and errors endpoint will return a 404 - Not Found response as long as the job is not completed. After that
a 204 - No Content indicates a completed job, but no results respectively errors. Check the job status to
identify which endpoint has data.
Wait for completion
If a notification is not feasible, the status of a job or better of multiple can be polled.
If the status changes to completed the job is done.
It is recommended to poll the general list of multiple jobs endpoint /batch/jobs with a filter for status. If only one job is executed
at a time, also the individual job status endpoint /batch/jobs/{jobId} can be used.
It is NOT recommended to poll the results or errors endpoint. These have a lower rate limit and may lead to 429 - Too Many Requests error response.
Result
The result can be in a column-based format similar to the input or as JSONL (ALPHA).
See output data for details.
| Service | Output Columns |
|---|---|
| Geocode | recId, seqNumber, seqLength, position, address, title |
| RevGeocode | recId, seqNumber, seqLength, position, distance, addressLabel |
| Lookup | recId, position, addressLabel |
Error report
The errors endpoint always returns a column-based output. The headers are fixed here, but the outputDelimiter parameter
is respected.
The output columns for errors are:
| Columns | Description | Example |
|---|---|---|
recId | Reference to input record. InputLine_ plus a number if a line could not be parsed. | 001, InputLine_1 |
errorCode | http error code in case of a 4xx or 5xx response from backend. A generic 999 in case of validation errors | 400, 999 |
errorMessage | JSON formated error message. This is the body of the backend response or a similar formated message in case of validation errors | <JSON> |
Examples
Input line has imbalanced quotes:
recId|errorCode|errorMessage
InputLine_1|999|{"status":999,"recordId":"InputLine_1","title":"Illegal input line","cause":"The input line does not conform to given input format for job.","action":"Please check format for job record and resubmit in new job.","jobRecord":"1,\"Sturmstraße 8, 80687 München,DEU"}Invalid backend parameter. Here show=something
recId|errorCode|errorMessage
1|400|{"status":400,"title":"Illegal input for parameter 'show'","cause":"Actual parameter value: 'something,si'","action":"Unsupported value: 'something'. Supported values: 'countryInfo', 'parsing', 'postalCodeDetails', 'secondaryUnitInfo', 'streetInfo', 'tz'","correlationId":"af357302-4e4c-4a59-8d24-c1eee5b98ed7","requestId":"1864f615-752f-4bed-a8e9-207625e88cc7-1"}Related information
Updated this month