Core Concept

Execution Plan

Every request in TiefWise goes through a deterministic execution pipeline. What you preview is exactly what gets sent. No exceptions.

What is an Execution Plan?

In most API clients, when you click "Send," the tool assembles and fires your request in one step. Variables are resolved on the fly. Cookies are read at transmission time. Redirects happen silently. You never see the final request that actually went out.

TiefWise works differently. Every request is first compiled into an Execution Plan — a fully resolved, validated, immutable snapshot of exactly what will be sent. You review it. Then you execute it.

ℹ️ Definition

An Execution Plan is TiefWise's internal representation of a fully resolved, validated request ready for transmission. Once generated, the plan is immutable — what you preview is character-for-character what the server receives.

The Pipeline

From raw request to executable plan in six deterministic steps.

1

Capture RequestState

The raw request as you built it in the editor is captured: URL, HTTP method, headers, body, authentication, and per-request settings.

method: POST
url: {{baseUrl}}/api/users
auth: Bearer {{token}}
body: {"name": "{{userName}}"}
2

Resolve Variables

All {{variables}} are substituted from the active environment. Every variable must resolve.

⚠️ No silent failures

Unlike other clients, TiefWise will not send a request with unresolved variables. If {{token}} doesn't exist in the active environment, the plan fails to generate. You fix it first.

url: https://api.example.com/api/users
auth: Bearer eyJhbGci...
body: {"name": "Alice"}
3

Freeze Cookie State

Cookies are captured at plan-generation time. No cookie can change between preview and execution. This eliminates an entire class of bugs. See TOCTOU below.

4

Apply Redirect Rules

The plan previews exactly how redirects will be followed. A 301 that changes your POST to GET? You see it before sending. See Redirect Behavior below.

5

Validate Authentication

Auth tokens are resolved and validated. SecretGuard boundaries are checked to ensure credentials stay within their allowed scope.

6

Generate Final Payload

The exact bytes that will be sent to the server. Character-for-character, what you see in the preview is what the server receives. The plan is now immutable.

TOCTOU: Why Freezing State Matters

TOCTOU (Time of Check, Time of Use) is a classic race condition: the state you checked isn't the state that gets used. In API clients, this happens constantly. You preview a request, cookies change from a background tab, and the request that fires is different from what you saw.

Traditional:
[Preview] —cookie changes—> [Send] = different request!
TiefWise:
[Generate Plan] —frozen—> [Preview] —frozen—> [Execute] = identical!
💡 Regenerating the plan

You can regenerate the plan at any time to capture fresh state. But once generated, the plan is immutable. Preview and execution are always the same.

Redirect Behavior: 301 vs 307

Not all redirects are equal. Some silently change your HTTP method. TiefWise makes this explicit in the Execution Plan.

Code Name Method Change? TiefWise Behavior
301 Moved Permanently Yes → GET Warned in plan before sending
302 Found Yes → GET Warned in plan before sending
307 Temporary Redirect No Method preserved, shown in plan
308 Permanent Redirect No Method preserved, shown in plan
🚨 Silent method changes

A 301 redirect silently changes your POST to a GET in most API clients. You never know it happened. TiefWise shows you this in the Execution Plan before the request is sent.

The WYPIWE Guarantee

What You Preview Is What Executes

The Execution Plan is generated once, validated once, and executed exactly as previewed. There is no gap between what you see and what runs.

Variables are resolved before preview — no runtime substitution surprises
Cookies are frozen at plan time — no mid-flight mutation
Redirect behavior is declared upfront — no silent method changes
Security checks pass before execution — not after