GuidesAPI Reference
Guides

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.

ServiceOutput Columns
GeocoderecId, seqNumber, seqLength, position, address, title
RevGeocoderecId, seqNumber, seqLength, position, distance, addressLabel
LookuprecId, 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:

ColumnsDescriptionExample
recIdReference to input record.
InputLine_ plus a number if a line could not be parsed.
001, InputLine_1
errorCodehttp error code in case of a 4xx or 5xx response from backend.
A generic 999 in case of validation errors
400, 999
errorMessageJSON 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