MindStudio HTTP Request Block Skill

Configure and use the MindStudio HTTP Request block to send data to external APIs, webhooks, and web services. Use this skill whenever a user mentions HTTP r...

A production reference for configuring the HTTP Request block correctly, reliably, and safely across any MindStudio workflow.

---

Step 1: Identify the Scenario and Interview the User

Before writing any configuration, determine what the user is trying to do. Match their intent to one of the five scenarios below, then ask only the questions listed for that scenario. Do not ask questions from other scenarios. Do not guess at variable names — use exactly what the user provides.

If the user's intent is already clear from context (e.g. they said "POST my AI output to a Make webhook"), skip straight to the questions for that scenario without asking them to confirm the scenario type.

---

Scenario A: Fetch Data (GET)

Trigger: User wants to retrieve data from an API — weather, stock prices, user records, CRM contacts, etc.

Ask the user:

1. What is the API endpoint URL? (full URL including any path)
2. Does the endpoint require an API key or token? If yes, what is the header name (e.g. Authorization, X-Api-Key)?
3. Are there any query parameters needed to filter or specify the data? (e.g. symbol=AAPL, user_id={{userId}})
4. What data do you need from the response? (so downstream handling can be configured correctly)

Method: GET Body: None Content-Type: none

---

Scenario B: Send Data (POST)

Trigger: User wants to submit data to an external system — form submissions, JSON payloads, lead captures, AI output delivery, etc.

Ask the user:

1. What is the endpoint URL you are sending to?
2. Does the endpoint require an API key or token? If yes, what is the header name?
3. What variables from your workflow do you want to send? List the exact variable names (e.g. {{customer_name}}, {{ai_output}}, {{email}}).
4. Does the endpoint expect JSON, form data, or plain text?
5. What do you expect back in the response? (e.g. a confirmation ID, a status field, nothing)

Method: POST Content-Type: application/json (default unless user specifies otherwise)

---

Scenario C: Update or Modify (PATCH / PUT)

Trigger: User wants to update an existing record in an external system — CRM contact, database row, project record, etc.

Ask the user:

1. What is the base endpoint URL? (e.g. https://api.example.com/contacts)
2. What is the record ID variable name in your workflow? (e.g. {{contact_id}}, {{record_id}}) — this gets appended to the URL
3. Are you updating specific fields only (PATCH) or replacing the entire record (PUT)?
4. Which fields are being updated? List the exact variable names and what each field represents.
5. Does the endpoint require an API key or token? If yes, what is the header name?
6. What do you expect back in the response?

Method: PATCH (partial update) or PUT (full replacement) Content-Type: application/json

---

Scenario D: Delete a Resource (DELETE)

Trigger: User wants to remove a record or resource from an external system.

Ask the user:

1. What is the base endpoint URL?
2. What is the record ID variable name in your workflow? (gets appended to the URL)
3. Does the endpoint require an API key or token? If yes, what is the header name?
4. Confirm: this action is permanent. Is that the intent?
5. What do you expect back in the response? (many DELETE endpoints return 204 with no body)

Method: DELETE Body: None Content-Type: none

Safety rule: Never generate a DELETE configuration without explicit confirmation from the user that removal is the intended action.

---

Scenario E: Trigger an External System

Trigger: User wants to fire a signal to an external system when something happens in the workflow — webhooks, Make/Zapier triggers, notifications, pipeline kicks, inter-workflow calls, etc.

Ask the user:

1. What is the webhook or trigger URL?
2. Does it require any authentication headers? (many webhooks do not)
3. What data do you want to include in the trigger payload? List exact variable names.
4. What does the external system return on success? (e.g. Make returns {"accepted": true}, some return 200 with no body)
5. Is there anything that should happen in the workflow after the trigger fires? (e.g. branch on success/failure, log the result)

Method: POST Content-Type: application/json

---

Step 2: Generate the Block Configuration

Once the user answers the questions for their scenario, output a complete, ready-to-paste block configuration using this structure:

URL          : [full URL, with variables where needed]
Method       : [GET / POST / PATCH / PUT / DELETE]
Content-Type : [application/json / none / other]

Headers:
  [Key]  : [Value]
  [Key]  : [Value]

Parameters (GET only):
  [key]  : [value]

Body:
[JSON or form structure using exact variable names]

Output Variable: [descriptiveName]

Then immediately follow with the downstream handling block:

On success (ok = true):
  - [what to do with the response]
  - [how to access specific fields]

On failure (ok = false):
  - Check {{outputVar.status}} for error code
  - [recommended branch or fallback]

---

Block Output Fields

Every HTTP Request block returns four fields regardless of method or endpoint:

Field	Type	Description
ok	Boolean	true if response status is in the 2xx range
status	Number	Numeric HTTP status code (e.g. 200, 404, 500)
statusText	String	Status description (e.g. "OK", "Not Found")
response	String	Full response body as a raw string

Access them downstream using:

{{outputVar.ok}}
{{outputVar.status}}
{{outputVar.statusText}}
{{outputVar.response}}

If the response body is JSON, pass {{outputVar.response}} to a downstream Generate Text or Run Function block to parse and extract fields. Never access nested fields directly from the raw response string.

---

Configuration Field Reference

URL

• Must be a complete, valid URL including https://
• Variables are supported: https://api.example.com/users/{{userId}}
• Never hardcode API keys or tokens in the URL — use headers

Method

Method	Use Case
GET	Retrieve data — no body
POST	Create a resource or trigger an action
PATCH	Partially update an existing resource
PUT	Fully replace an existing resource
DELETE	Remove a resource — no body
HEAD	Retrieve headers only
OPTIONS	Discover available methods

Headers

Content-Type    : application/json
Authorization   : Bearer {{apiKey}}
Accept          : application/json
X-Api-Key       : {{serviceKey}}

• Always include Content-Type when sending a body
• Always include Authorization when the endpoint requires it
• All values support {{variable}} syntax

Parameters

Query string key-value pairs. Used with GET requests.

symbol    : {{ticker}}
token     : {{apiKey}}
from      : {{startDate}}

Content Type

Option	When to Use
application/json	Structured JSON data (most common)
application/x-www-form-urlencoded	HTML form submissions
multipart/form-data	File uploads or mixed form data
text/plain	Raw text payloads
application/XML	XML-based APIs
custom	Any content type not in this list
none	GET, HEAD, DELETE — no body

Body

For application/json:

{
  "customer_name": "{{customer_name}}",
  "email": "{{email}}",
  "ai_output": "{{generatedText}}",
  "submitted_at": "{{timestamp}}"
}

For application/x-www-form-urlencoded:

customer_name={{customer_name}}&email={{email}}

For GET / DELETE: Leave body empty. Set Content-Type to none.

Output Variable

Always set this. Use a descriptive name that reflects the source.

makeResponse
crmResult
stockData
userRecord
patchResult

---

Request Construction Rules

1. Method selection — POST for create/trigger, PATCH for partial update, PUT for full replace, GET for read-only, DELETE for removal
2. Headers — always include Content-Type when sending a body; always include auth headers when required; never omit required headers
3. Body — every field must come from a real workflow variable or a hardcoded literal; never invent field values
4. Variables — use {{variableName}} syntax everywhere; use dot notation for nested data from upstream blocks
5. Output variable — always name it; always check ok before using response downstream

---

Output Handling

Success (ok = true, 2xx)

1. Check {{outputVar.ok}} is true before proceeding
2. Access raw body via {{outputVar.response}}
3. If body is JSON, parse it in a downstream block before using individual fields
4. Store or log relevant fields for use in the rest of the workflow

Failure (ok = false, 4xx or 5xx)

Status	Meaning	Fix
400	Bad Request	Body is malformed or missing required fields
401	Unauthorized	Missing or invalid API key / token
403	Forbidden	Valid key but insufficient permissions
404	Not Found	URL is wrong or resource does not exist
422	Unprocessable Entity	JSON is valid but field values are invalid
429	Rate Limited	Too many requests — add a Wait block
500	Server Error	External API issue — retry or alert
503	Service Unavailable	External API is down — retry later

Malformed Response

• Do not parse a non-JSON response as JSON
• Route to an error branch and log {{outputVar.response}} for debugging
• Never pass raw malformed content to downstream AI blocks

---

Reliability Rules

Missing required data:

• Use a Condition block upstream to verify required variables are not empty before the HTTP Request block runs
• If a required field is missing, route to an error message block — never send an incomplete request

API failure:

• Always check {{outputVar.ok}} immediately after the block
• Branch on failure — never assume success

Retry logic:

• Add a Wait block between retries for flaky endpoints (rate limits, 503s)
• Maximum 2-3 retries before routing to a permanent failure state
• Never retry on 4xx — those are logic or config errors, not transient failures

Response validation:

• Verify {{outputVar.response}} is non-empty after a 2xx
• Confirm expected fields exist before passing to downstream blocks

---

Safety Rules

Absolute. No exceptions.

1. Never send undefined or empty variables in the request body — validate upstream first
2. Never hallucinate field names — use only field names confirmed by the user or API documentation
3. Never hardcode API keys, tokens, or passwords in the URL or body — always inject via workflow variable
4. Never send a body with GET, HEAD, or DELETE requests
5. Never omit Content-Type when sending a body — mismatches cause silent failures
6. Never pass raw response strings to downstream AI blocks without labeling the format
7. Never retry on 4xx errors — retrying will not fix a bad request
8. Never generate a DELETE configuration without explicit user confirmation of intent

---

Example Configurations

Example 1: GET — Fetch Stock Quote from Finnhub

URL          : https://finnhub.io/api/v1/quote?symbol={{ticker}}&token={{finnhubApiKey}}
Method       : GET
Content-Type : none
Headers      :
  Accept : application/json
Body         : (empty)
Output Variable: stockData

On success: parse {{stockData.response}} — field "c" is current price
On failure: log {{stockData.status}} — check API key and ticker symbol

---

Example 2: POST — Send AI Output to Make Webhook

URL          : https://hook.us1.make.com/{{webhookId}}
Method       : POST
Content-Type : application/json
Headers      :
  Content-Type : application/json
Body:
{
  "customer_name": "{{customer_name}}",
  "email": "{{email}}",
  "ai_output": "{{generatedText}}",
  "submitted_at": "{{timestamp}}"
}
Output Variable: makeResponse

On success: Make returns {"accepted": true} — log and continue
On failure: log {{makeResponse.status}} — verify webhook URL is active

---

Example 3: PATCH — Update a CRM Contact

URL          : https://api.hubspot.com/crm/v3/objects/contacts/{{contact_id}}
Method       : PATCH
Content-Type : application/json
Headers      :
  Content-Type  : application/json
  Authorization : Bearer {{hubspotApiKey}}
Body:
{
  "properties": {
    "lead_score": "{{lead_score}}",
    "last_contacted": "{{timestamp}}",
    "notes": "{{ai_summary}}"
  }
}
Output Variable: crmResult

On success: {{crmResult.ok}} = true — record updated
On 404: contact_id is wrong — check the variable source block
On 422: field name mismatch — verify HubSpot property names

---

Example 4: DELETE — Remove a Resource

URL          : https://api.example.com/records/{{record_id}}
Method       : DELETE
Content-Type : none
Headers      :
  Authorization : Bearer {{apiKey}}
Body         : (empty)
Output Variable: deleteResult

On success: status 204 — no body returned, deletion confirmed
On 404: record_id does not exist or was already deleted
On 403: API key does not have delete permissions

---

Example 5: POST — Trigger a Zapier Webhook

URL          : https://hooks.zapier.com/hooks/catch/{{zapId}}/{{hookId}}/
Method       : POST
Content-Type : application/json
Headers      :
  Content-Type : application/json
Body:
{
  "event": "workflow_completed",
  "user_email": "{{email}}",
  "result": "{{ai_output}}",
  "timestamp": "{{timestamp}}"
}
Output Variable: zapierResponse

On success: Zapier returns {"status": "success"} — trigger confirmed
On failure: log {{zapierResponse.status}} — verify Zap is active and URL is correct

---

Pre-Flight Checklist

URL and method:

• URL is complete and starts with https://
• Method matches the intended operation
• Dynamic values in the URL use {{variableName}} syntax

Headers:

• Content-Type is set and matches the body format
• Auth header is included if the endpoint requires it
• API key is injected from a variable — not hardcoded

Body:

• Content Type in block settings matches the Content-Type header
• Every field uses a real workflow variable or literal value
• No field has an undefined or empty variable
• Body is empty for GET and DELETE requests

Output:

• Output Variable is named and descriptive
• Downstream blocks check {{outputVar.ok}} before using {{outputVar.response}}
• A failure branch exists for ok = false