Jetic/curl
curl sends one request and prints what came back. Jetic runs a workflow: an ordered list of JSON steps where each response can be captured into memory and injected into the next call, so a login token, a generated email, or a workspace ID carries through the whole journey.
The runner is deterministic. Steps execute in order, every expectStatus is checked, and no model decides what happens mid-run.
curl
One request, one response. You hold the state.
$ curl -i http://localhost:3000/api/users/123
HTTP/1.1 200 OK
content-type: application/json
{ "id": 123, "name": "Ada" }
Jetic
Ordered steps. Captured state. Injected headers.
capture accessToken ← data.tokens.access
inject header:Authorization
curl can be scripted and run in CI, and for a single endpoint it usually is the right tool. The difference shows up once a test has more than one step: curl moves data between calls through your shell, Jetic keeps it in workflow memory.
| Comparison | curl | Jetic |
|---|---|---|
| Primary purpose | Send HTTP requests and inspect the response | Run stateful API journeys from a model of your code |
| How a call is defined | Flags typed into a shell command | A JSON step inside a workflow file |
| API context | You supply the URL, headers, and payload | The endpoint comes from model.json, built by a static scan of your routes |
| State between calls | Shell variables and glue code you write | capture stores response fields in memory; inject sends them into later steps |
| Auth across steps | Copy the token into every call by hand | Capture the token once, inject Authorization on each protected step |
| Repeatability | Whatever the script does on that machine | The same ordered steps on every run — nothing is inferred at execution time |
| Expectations | Read the output and compare by eye | expectStatus asserts each step; continueOnStatus, onFailure and retry cover the edges |
| AI involvement | An agent can run curl commands | An agent authors and validates the workflow over MCP; the runner executes it without an LLM |
| Version control | Scripts, if you keep them | Workflows and the model are JSON files in .jetic/, reviewed like code |
| Best fit | One-off requests, headers, quick debugging | Journeys where the sequence and the state are the thing being tested |
$ curl -i -X POST \
-H "Content-Type: application/json" \
-d '{"name":"Ada"}' \
localhost:3000/api/users
HTTP/1.1 201 Created
curl: Direct HTTP control
Send requests, specify headers, pass payloads, and inspect the response. curl remains an excellent tool for quick debugging and low-level HTTP work.
Jetic: the route, not a hand-typed URL
jetic scan reads tsconfig.json and walks the Express router chain — nested prefixes, path parameters, auth middleware, and the source file and line behind each route — then writes them to model.json. Steps reference an endpoint by method and path.
2 login 200
capture
inject
Jetic: capture → memory
capture writes response fields into run memory using dot-notation paths; captureInput remembers generated request values before the call. Later steps read them as {{workflow:key}}, so the token from step 2 is the Authorization header in step 3.
Jetic: deterministic execution
A workflow is JSON in .jetic/workflows/. Steps run in order and each expectStatus is asserted; retry, continueOnStatus and onFailure are written in the file. Same file in, same sequence out — no model picks the path.
curl + Jetic
Probe a single request with curl while you are figuring out the payload. Once the sequence matters, encode it as a workflow and let the runner replay it.
The same three-step journey: register, log in, create an order. Both versions work. The difference is who moves the token between step 2 and step 3.
# register
curl -s -X POST localhost:3000/api/users \
-H 'content-type: application/json' \
-d '{"email":"ada@example.com","password":"s3cret"}'
# log in, then pull the token out yourself
TOKEN=$(curl -s -X POST localhost:3000/api/auth/login \
-H 'content-type: application/json' \
-d '{"email":"ada@example.com","password":"s3cret"}' \
| jq -r .data.tokens.access)
# create an order as that user
curl -i -X POST localhost:3000/api/orders \
-H "authorization: Bearer $TOKEN"Works, but the token only exists in your shell. Every new step means another variable, another jq path, and another chance to point at the wrong environment.
{
"name": "User onboarding",
"steps": [
{ "name": "1. Register", "method": "POST", "path": "/api/users",
"expectStatus": 201,
"body": { "email": "{{faker.internet.email}}" },
"captureInput": { "workflow:email": "email" } },
{ "name": "2. Log in", "method": "POST", "path": "/api/auth/login",
"body": { "email": "{{workflow:email}}" },
"capture": { "workflow:accessToken": "data.tokens.access" } },
{ "name": "3. Create order", "method": "POST", "path": "/api/orders",
"inject": { "header:Authorization": "Bearer {{workflow:accessToken}}" } }
]
}The runner generates the email, remembers it, captures the token from the login response, and injects it as a header. Re-run it with jetic simulate workflow — same file, same order, same result.
When should you use curl or Jetic?
when you need to send one request, inspect headers, debug an endpoint, or write a small shell script. Nothing beats it for a direct HTTP call.
when the test is a journey: capture the token from login, reuse the generated email, inject the header on every protected step, and re-run the same JSON file tomorrow.
Probe with curl while you work out a payload, then encode the sequence as a workflow once the order of steps starts to matter.
No. curl is still the fastest way to send one request and look at what comes back. Jetic covers the layer above it: a model of your endpoints plus ordered, stateful steps that you can re-run.
Yes. Every workflow step is an HTTP call against a live server, addressed with a method and path from model.json. jetic simulate workflow runs the whole list in order.
Yes, with a shell script and something like jq to pull values out of JSON. You write the token plumbing yourself for every step. Jetic declares the capture and the injection once, in the workflow file.
Two directions. captureInput saves resolved request fields before the call — generated emails and passwords you will need again. capture saves response fields after a successful response, using dot-notation paths such as data.tokens.access. Both land in run memory, and later steps read them as {{workflow:key}}.
Yes. The runner walks the JSON steps in order and checks each expectStatus. Conditions, continueOnStatus, onFailure and retry are all written in the file, so nothing is decided by a model at execution time.
No. jetic init, jetic scan and jetic simulate workflow are keyless. MCP is there for authoring and validation with an agent, not for executing the run.
Yes. The agent builds or edits the workflow with jetic_validate_workflow and jetic_create_workflow, then the CLI runner executes the saved file. The model writes the steps; it does not take part in the run.
For Express + TypeScript, jetic scan reads tsconfig.json and the router chain: paths, path parameters, nested prefixes, auth middleware, and the source file and line of each route. Schemas and business constraints are added in Studio or through MCP.
Yes. Workflows are files, so a job only needs jetic simulate workflow --workflow .jetic/workflows/<name>.json. Prompts for genuinely unknowable values, such as an OTP, can be supplied through environment variables so the run never blocks.