HTTP Request Step
The HTTP Request step calls external APIs and web services. Use it to fetch data, send notifications, update external systems, or integrate with any service that has a REST API. Unlike agent tools (which agents use intelligently), HTTP Request gives you explicit control over API calls.When to use HTTP Request vs. Agent Tools: Use HTTP Request when you need explicit control over the API call (specific endpoint, exact parameters, precise error handling). Use Agent Tools when you want the agent to intelligently decide when and how to call APIs.
How HTTP Requests Work
HTTP Requests send data to external endpoints and return responses that subsequent steps can use:Configuration
Request Settings
HTTP methodOptions:
GET- Retrieve data (most common)POST- Create new resource or submit dataPUT- Update existing resource (replace)PATCH- Update existing resource (modify)DELETE- Remove resourceHEAD- Get headers only (no body)OPTIONS- Check allowed methods
- GET: Fetch user profile, list orders
- POST: Create customer, send notification
- PUT: Update entire record
- PATCH: Update specific fields
- DELETE: Remove item, cancel subscription
API endpoint URLCan include variables from previous steps:Best practices:
- Always use HTTPS (not HTTP)
- Include API version in URL if available
- Verify URL is correct before deploying
Request headersCommon headers:Can include variables:
Request body (for POST, PUT, PATCH)JSON body:Can reference entire objects:Note: Body is automatically JSON-encoded. For form-data or other formats, use appropriate Content-Type header.
URL query parametersExample:Automatically appended to URL:Can use variables:
Authentication
Authentication configurationTypes:
- Bearer Token
- API Key
- Basic Auth
- OAuth 2.0
- Custom
Most common for modern APIsAdds header:
Authorization: Bearer <token>Response Handling
Response Structure
HTTP Request returns:Accessing Response Data
Reference response in subsequent steps:Error Handling
Automatic retry configurationSettings:
maxRetries: Number of retry attemptsretryDelay: Initial delay between retries (ms)retryOn: Status codes that trigger retrybackoffMultiplier: Increase delay each retry (exponential backoff)
Request timeout in millisecondsRequest fails if no response within timeout period.Recommendations:
- Fast APIs: 5000ms (5 seconds)
- Standard APIs: 30000ms (30 seconds)
- Slow APIs: 60000ms (60 seconds)
- Long operations: 120000ms+ (2+ minutes)
Status codes that should be treated as failuresBy default, only 5xx codes fail. Use this to also fail on specific 4xx codes.
Error Response
When request fails:Common Patterns
Fetch Data for Agent
Fetch Data for Agent
Get external data before agent processesUse when: Agent needs context from external systems
Send Agent Output to API
Send Agent Output to API
Agent generates content, HTTP sends to external systemUse when: Agent creates content for external systems
Sequential API Calls
Sequential API Calls
Chain multiple API calls using previous responsesUse when: Need data from multiple endpoints
Parallel API Calls
Parallel API Calls
Call multiple APIs simultaneously (not sequential)Use when: Need data from multiple sources, order doesn’t matterNote: Configure parallel execution in flow settings
Webhook Response
Webhook Response
Respond to webhook with HTTP callUse when: Webhook requires acknowledgment
Error Handling with Retry
Error Handling with Retry
Retry failed requests with backoffUse when: External APIs may have temporary failures
Rate Limit Handling
Rate Limit Handling
Check and respect rate limitsUse when: API has rate limits you need to respect
Pagination Handling
Pagination Handling
Iterate through paginated resultsUse when: API returns paginated results
Real-World Examples
Example 1: CRM Contact Creation
Scenario: Create or update contact in CRM after agent qualifies leadExample 2: Slack Notification
Scenario: Send notification to Slack when high-value order placedExample 3: Email via SendGrid
Scenario: Send personalized email after agent generates contentExample 4: Database Query via API
Scenario: Query database for customer order historyExample 5: Payment Processing
Scenario: Process payment through StripeBest Practices
Use HTTPS
Always use HTTPS endpoints (not HTTP) for security. API keys and data are encrypted in transit.
Store Secrets Securely
Never hardcode API keys. Use Secrets Manager and reference with
${secrets.key_name}.Handle Errors
Always add error handling with Conditions. Check status codes and have fallback flows.
Set Appropriate Timeouts
Set timeouts based on expected API response time. Don’t leave default if API is slow.
Use Retry for Transient Failures
Enable retry for 5xx errors and network issues. Use exponential backoff to avoid overwhelming APIs.
Validate Responses
Check that response has expected structure before using data. Use Conditions to verify.
Respect Rate Limits
Check rate limit headers. Add delays if approaching limits.
Log for Debugging
Monitor HTTP requests in flow execution logs. Review failures to improve error handling.
Troubleshooting
401 Unauthorized
401 Unauthorized
404 Not Found
404 Not Found
Causes:
- Wrong URL or endpoint
- Resource doesn’t exist
- Variable in URL not populated
- Double-check URL spelling
- Verify endpoint in API docs
- Check variable references:
${trigger.id}not${id} - Test URL manually in browser/Postman
500 Server Error
500 Server Error
Causes:
- API is down
- Invalid request body
- Server-side bug
- Check API status page
- Verify request body structure
- Enable retries for transient failures
- Contact API provider if persistent
Timeout
Timeout
Causes:
- API too slow
- Timeout too short
- Network issues
- Increase timeout setting
- Check API performance/status
- Optimize API call (reduce data)
- Use async/background processing if possible
Can't access response data
Can't access response data
Causes:
- Wrong variable path
- Response not JSON
- API returned error
- Check execution logs for actual response
- Verify response is JSON (
Content-Type: application/json) - Check for error response instead of success
- Try
${http.rawBody}to see exact response
CORS Error
CORS Error
Note: CORS errors don’t apply to QuivaWorks flows (server-side). If you see CORS errors:
- You’re likely testing from browser console
- Flows run server-side and don’t have CORS restrictions
- The API might not allow your testing origin
Security Best Practices
API Key Management
API Key Management
Do:
- Store keys in Secrets Manager
- Rotate keys regularly (every 90 days)
- Use separate keys for dev/staging/prod
- Revoke immediately if compromised
- Monitor key usage
- Hardcode keys in flows
- Share keys in chat or email
- Use same key across environments
- Commit keys to version control
Input Validation
Input Validation
Always validate and sanitize user input before including in API calls:Never pass raw user input directly to APIs without validation.
Rate Limiting
Rate Limiting
Implement your own rate limiting:
- Track API calls per user/session
- Add delays if approaching limits
- Cache responses when possible
- Use webhooks instead of polling
Error Message Sanitization
Error Message Sanitization
Don’t expose sensitive information in errors:Bad:Good: