Agent: restapi
Calls configured REST API endpoint and saves response as JSON file.
Used for getting data from a REST API and saving the response into a file.
Typical flow:
restapi -> saves JSON file
json -> loads JSON file into target table
For repeated API calls:
restapi -> creates response files + index file
json -> reads index file, loads response files, deletes processed files
Current limitation
restapi currently expects API response to be valid JSON.
The agent parses the response as JSON before saving it into a file. Because of that, non-JSON responses such as plain text or XML are not supported yet.
This may change later if restapi is extended to work as a more general response/content downloader.
API definition
API connection information is kept in route-level route.yaml.
File location:
routes/{route}/route.yaml
Example route.yaml:
api_alias:
url: "https://www.example.com/" # root url
method: GET # optional; default: GET
auth: # optional; default: public auth
method: public # public | basic | bearer; default: public
username: "%BASIC_API_USER%" # for basic
password: "%BASIC_API_PASSWORD%" # for basic
token: "%API_TOKEN%" # for bearer
headers:
Accept: "application/json"
Minimal:
api_alias:
url: "https://www.example.com/"
headers:
Accept: "application/json"
If method is missing, GET is used.
If auth is missing, API is treated as public:
auth:
method: public
route.yaml uses top-level keys as API aliases. In haulwork.yaml, api_source.api references one of those aliases.
Single request
- do: restapi
api_source:
api: public_request
path: "/haridusasutused"
single_destination:
type: task
file: haridusasutused.json
Single request saves one API response into single_destination.
TODO: POST and request body support exists, but docs should be expanded later when session/token extraction and dependent requests are implemented.
If values need to be inserted into the URL path or saved for later JSON processing, use repeated requests with repeat or repeat_sql.
Repeated requests
Repeated requests are used when the same API endpoint must be called several times with different parameters.
- do: restapi
api_source:
api: public_request
path: "/haridusasutused/{{jrk}}"
repeat:
- params:
jrk: 17
- params:
jrk: 18
repeat_index:
type: task
file: unprocessed_files.json
mode: append
This creates separate response files and writes their paths with used parameters into unprocessed_files.json.
Example index file:
[
{
"file": "work/routes/test_route/public/schools/restapi_20260721_134739_579796.json",
"params": {
"jrk": 17
}
}
]
Repeated response file location
Repeated response files are saved next to the index file.
Continue on error
By default, repeated requests stop on the first failed API request.
If some repeat params may fail but the next ones should still be processed, use continue_on_error.
- do: restapi
api_source:
api: public_request
path: "/haridusasutused/{{jrk}}"
repeat:
- params:
jrk: 17
- params:
jrk: 18
continue_on_error: true
repeat_index:
type: task
file: unprocessed_files.json
mode: append
If continue_on_error is true, failed repeat params are logged and the agent continues with the next params.
Only successful responses are saved as response files and added to repeat_index.
If continue_on_error is missing or false, the first failed repeated request stops the action.
Repeated requests from SQL
repeat_sql can be used when repeat parameters should come from target database.
- do: restapi
api_source:
api: public_request
path: "/haridusasutused/{{jrk}}"
repeat_sql:
file: repeat.sql
mapping:
jrk: 1
aeg: 2
repeat_index:
type: task
file: unprocessed_files.json
mode: append
repeat_sql.file is read from current task directory.
repeat_sql.mapping maps parameter names to SQL result column positions. Column positions start from 1.
Example repeat.sql:
SELECT 17, 'hommik'
UNION
SELECT 18, 'lõuna'
Using repeat and repeat_sql together
repeat and repeat_sql may both be used. In that case manually defined repeat params are processed first, then SQL params.
Repeat index mode
repeat_index controls where repeated response files are tracked.
repeat_index:
type: task
file: unprocessed_files.json
mode: append
Default values:
repeat_index.type -> task
repeat_index.file -> unprocessed_files.json
repeat_index.mode -> append
Supported modes:
append - keep old index entries and append new ones
override - delete files from old index, clear index, then write new entries
In override mode, files listed in the previous index file are deleted before the new index is created. This prevents old response files from becoming orphaned when the index is overwritten.
Single destination
For non-repeated requests, response is saved to single_destination.
single_destination:
type: task
file: response.json
If repeat logic is used, single_destination is ignored.
File pointers
single_destination and repeat_index use file pointers. See File pointers.
Normal usage is to save files into current task folder:
type: task
file: response.json
Filesystem folders can be used with type: fs.
type: fs
dir: "/tmp/somepath"
file: response.json
Required and optional settings
Required in haulwork.yaml for single request:
do
api_source
api_source.api
single_destination
single_destination.type
single_destination.file
Required in haulwork.yaml for repeated requests:
do
api_source
api_source.api
repeat or repeat_sql
Optional:
api_source.path
api_source.method
api_source.params
api_source.headers
api_source.body
api_source.timeout
api_source.retry
continue_on_error
repeat_index
repeat_index.type
repeat_index.file
repeat_index.mode
single_destination
Default values:
api_source.method -> route.yaml method or GET
api_source.timeout -> route.yaml timeout or 30
repeat_index.type -> task
repeat_index.file -> unprocessed_files.json
repeat_index.mode -> append
Path parameters
Repeat params can be used in api_source.path.
api_source:
api: public_request
path: "/schools/{{jrk}}"
repeat:
- params:
jrk: 17
This creates request path:
/schools/17
Both forms are supported:
{{jrk}}
{{ jrk }}
Authentication
Supported auth methods:
public
none
basic
bearer
token
public and none mean that no authentication is used.
Basic auth:
auth:
method: basic
username: "%API_USER%"
password: "%API_PASSWORD%"
Bearer auth:
auth:
method: bearer
token: "%API_TOKEN%"
token is treated as bearer token auth.
Environment variables are written as %ENV_VAR%.
Retry
Retry can be configured in route.yaml or action api_source.
retry: 3
Retry is used for temporary request failures and selected HTTP status codes:
429
500
502
503
504
Full pipeline sample
actions:
- do: restapi
api_source:
api: bearer_request
path: "/schools/{{jrk}}"
repeat:
- params:
jrk: 17
repeat_index:
type: task
file: unprocessed_files.json
mode: override
- do: json
origin:
type: task
file: unprocessed_files.json
file_is_index: true
cols:
- name: jrk
from: params
data: jrk
type: int
- name: arno_id
from: data
data: arno_id
type: int
- name: nimi
from: data
data: name
type: text
In this example, restapi calls API once for every repeat param set, creates response files, and writes them to unprocessed_files.json.
Then json reads unprocessed_files.json, imports response files into target table, removes processed response files from index, and deletes the index file when it becomes empty.
Remarks
- Current implementation expects API response to be valid JSON.
- Non-JSON response support is not implemented yet.
GETandPOSTmethods are supported.- Public, basic and bearer auth are supported.
- Sessioned auth and response extraction are not implemented yet.
- Use
single_destinationfor one response file. - Use
repeatorrepeat_sqlfor multiple API calls. continue_on_error: trueallows repeated requests to continue after failed params.