7.3 API and Send HTTP Request Responses

7.3 API and Send HTTP Request Responses

Quick Answer: In a topic, add Advanced → Send HTTP request, set URL and method (GET/POST/PATCH/PUT/DELETE), edit headers and body, choose response data type (often from sample JSON), and save the response to a variable. Configure error handling (raise vs continue) and timeout, then Parse value when you need typed fields for messages, conditions, prompts, or further tools.

AB-620 skill Configure advanced agent responses with API and Send HTTP requests measures whether you can pull or push live system data inside a conversation—order status, ticket create, inventory check—not only recite knowledge. Related Domain 2 skills cover REST API tools and connectors at agent scale; this section focuses on the topic HTTP node pattern and how it feeds advanced responses.

Where the HTTP Request node lives

On the topic authoring canvas:

1. Select Add node under the step that should precede the API call.
2. Point to Advanced → Send HTTP request.
3. Enter the URL (can include dynamic values where the product allows formula-driven segments).
4. Choose Method: GET, POST, PATCH, PUT, or DELETE.
5. Open Headers and body → Edit for the properties panel.
6. Set Response data type and Save user response as (new or existing variable).

That saved variable becomes the raw material for the next Message, Condition, Prompt, Adaptive Card, or tool call—the “response” half of advanced topic responses.

Headers, authentication, and body content

Headers

Add key/value headers for Content-Type, API version headers, correlation IDs, and authentication. Common pattern: Authorization: Bearer <token>. Tokens may come from:

• Environment-safe configuration patterns (prefer not hard-coding secrets in topics)
• User.AccessToken after end-user sign-in—only to trusted backends; Microsoft warns this variable contains user auth material and misuse harms the user
• Tokens returned earlier in the topic or from a secure flow

Never paste long-lived secrets into Message node text “for convenience.” Exam security vignettes punish that shortcut.

Body modes

Dynamic JSON is a frequent maker pitfall. When body is JSON, use the Formula path so values like Topic.OrderId are real Power Fx references. Community guidance matches Microsoft’s formula conversion: build a Power Fx object/record that serializes to JSON at send time rather than hand-escaping strings incorrectly.

Example intent (conceptual): POST a support ticket with title and priority taken from topic variables collected by questions or an Adaptive Card.

Response typing and Power Fx usage

On the node, pick how the response is typed. Providing sample JSON from the API docs (“Get schema from sample JSON”) generates a structured Power Fx shape with intellisense in later formulas. Without a schema, you still store the response but field access is harder and more error-prone.

Save into a clearly named variable (Topic.OrderApiResponse). Downstream:

• Message nodes show friendly fields (Order status is …)
• Conditions branch on status codes or business fields
• Custom prompts receive a compact string summary—not the entire raw dump unless required
• Adaptive Cards bind labels to parsed fields

Parse value

When the payload is a stringified JSON, an Any-typed error body, or a nested structure you need as a table/record, insert Variable management → Parse value. Pass the HTTP output (or error body), set the expected type (record/table), and store the parsed result. Parsing is also how you safely read Continue on error response bodies.

Error handling and timeout

Default behavior: failures Raise an error, stop the normal path, and trigger the On Error system topic with an error experience.

Alternative: Continue on error—store:

• HTTP status code → e.g. Topic.StatusCode
• Error response body → e.g. Topic.ErrorResponse (type Any; parse as needed)

Then branch: if status is 404, tell the user the order was not found; if 429/503, offer retry messaging; if 401, route to authentication topics. This is the production pattern for resilient advanced responses.

Request timeout defaults to 30 seconds (configured in milliseconds in properties). Long-running enterprise jobs should not block a single HTTP node forever—use async backend design, agent flows, or status-check patterns.

Scenario: order status topic

1. Authenticate the user if the API is per-user.
2. Ask for order number → Topic.OrderNumber.
3. Send HTTP request GET to https://api.contoso.com/orders/{order} with Bearer token header.
4. Response type from sample JSON; save as Topic.OrderResponse.
5. On success path, Message summarizes status, ETA, and tracking link fields.
6. Continue on error: 404 → “We could not find that order”; 5xx → “Systems are busy; try again” + optional create-ticket flow tool.
7. Optional: pass a short status string into a custom prompt to rewrite in the customer’s language—still grounded in API facts, not model invention.

When to use HTTP vs connector vs REST tool vs flow

Domain 2 will deepen OpenAPI REST tools and connectors; Domain 1 expects you to pick the right response path inside topics. A common wrong answer on exams is “always HTTP” when a first-party connector already exists with better auth and monitoring—or “always flow” for a one-line GET that a node handles cleanly.

Security and responsible use

• Send tokens only to trusted HTTPS endpoints.
• Minimize PII in URLs (prefer headers/body).
• Do not log raw User.AccessToken into transcript messages.
• Validate/sanitize user-provided IDs before concatenation into URLs.
• Pair HTTP writes (POST/PATCH/DELETE) with confirmation topics or human-in-the-loop flows when actions are high risk.
• Align with the agent’s responsible AI and security plan: tools that change data need clearer consent than knowledge reads.

Testing checklist for AB-620 labs

• Happy path with realistic sample JSON schema.
• 401/403 path with auth misconfiguration.
• 404 business-not-found messaging (continue on error).
• Timeout behavior under slow mock API.
• Variable nulls when optional JSON fields are missing—guard in conditions.
• Republish after schema changes; stale variables break field paths.
• Compare connector equivalent: if maintenance cost is high for hand-built HTTP, document why HTTP remains justified.

How HTTP completes the advanced response triad

Advanced topic responses on AB-620 combine all three: retrieve policy (knowledge), call order API (HTTP), rewrite the answer politely (prompt), then Message or Adaptive Card to the user. Configure each node so failures are visible, variables are typed, and generative steps cannot invent dollar amounts that the API never returned.

Master the HTTP Request node’s properties panel—method, headers, body formula, response schema, error handling, timeout—and you can defend every “advanced response” design choice in Domain 1.