This could indeed be very useful.
we have the following issue about it.

For the time-being, we have generated Hurl files for reuse.
Import might seem a good option, but it also brings a lot of questions/complexities (infinite recursive import loop, ...).

@spaceaardvark I've transformed this discussion to an issue #317 as we're going to only use issues

Request reuse in Hurl is the most-requested missing feature — here are the approaches that work today and what a native solution might look like:

Current workaround: templated files:

#!/bin/bash
# Use shell variables + envsubst
export AUTH_TOKEN=$(hurl --variables-file secrets.env auth.hurl | jq -r '.token')

# Then in other .hurl files, reference via variable
BASE_URL=https://api.example.com hurl --variable AUTH_TOKEN=$AUTH_TOKEN main.hurl

Current workaround: shell scripting + file composition:

# auth.hurl — just the auth request
POST https://{{base_url}}/auth
Content-Type: application/json
{"username": "{{user}}", "password": "{{pass}}"}

HTTP 200
[Captures]
token: jsonpath "$.token"

# api_call.hurl — uses captured token from auth.hurl
GET https://{{base_url}}/resource
Authorization: Bearer {{token}}

HTTP 200

# Run them in sequence, sharing captures
hurl auth.hurl api_call.hurl --variables-file .env

Hurl already chains requests in a single file and passes captures between them — the gap is that you can't define a "reusable request block" that can be included elsewhere.

What a native solution would look like:

# Hypothetical: import syntax
import auth from ./auth.hurl

GET https://api.example.com/data
Authorization: Bearer {{auth.token}}

The --include or import mechanism would need to define how captures from included files scope into the parent. Is there a GitHub issue tracking this specifically?