RAP Logo

http response

Send HTTP responses back to clients completing API workflows

http response Block

The http response block is used to send HTTP responses back to clients, completing API workflows started by http in blocks. It's essential for creating REST APIs and web services with RAPFlow.

Overview

The http response block completes the HTTP request-response cycle. It takes the processed data from your workflow and sends it back to the client that made the original request. This block must be used in conjunction with an http in block to create complete API endpoints.

Configuration Options

Response Content

  • Status Code: HTTP status code (200, 404, 500, etc.)
  • Headers: Custom HTTP headers to include in the response
  • Content-Type: Set the response content type (JSON, HTML, text, etc.)

Data Source

  • Send: Choose what to send in the response
    • msg.payload - Send the message payload
    • Complete message - Send the entire message object
    • Custom - Send specific properties

Response Format

  • JSON: Automatically format as JSON (most common)
  • Plain Text: Send as plain text
  • HTML: Send as HTML content
  • Binary: Send binary data (files, images)

Message Properties

The http response block uses these message properties:

{
    payload: /* data to send in response */,
    statusCode: /* HTTP status code (optional) */,
    headers: /* response headers (optional) */,
    cookies: /* cookies to set (optional) */,
    res: /* response object from http in block */
}

Common Use Cases

JSON API Response

Return processed data as JSON:

// Message payload
{
    "result": "success",
    "data": {
        "extracted_text": "Document content...",
        "confidence": 0.95
    },
    "statusCode": 200
}

File Download Response

Send processed files back to client:

{
    "payload": /* file buffer */,
    "headers": {
        "Content-Type": "application/pdf",
        "Content-Disposition": "attachment; filename=processed.pdf"
    }
}

Error Response

Return error information:

{
    "payload": {
        "error": "Document processing failed",
        "message": "Unsupported file format"
    },
    "statusCode": 400
}

Success Confirmation

Simple success response:

{
    "payload": {
        "status": "completed",
        "id": "doc_12345"
    },
    "statusCode": 201
}

HTTP Status Codes

Use appropriate status codes for different scenarios:

  • 200 OK: Successful processing
  • 201 Created: Resource created successfully
  • 400 Bad Request: Invalid input data
  • 404 Not Found: Resource not found
  • 422 Unprocessable Entity: Validation errors
  • 500 Internal Server Error: Processing errors

Best Practices

  1. Set appropriate status codes: Use standard HTTP status codes
  2. Include error details: Provide helpful error messages for failed requests
  3. Use consistent response format: Maintain consistent JSON structure
  4. Set content-type headers: Ensure correct content-type for your responses
  5. Handle file responses: Set appropriate headers for file downloads

Common Response Patterns

Standard JSON API Response

{
    "success": true,
    "data": /* processed result */,
    "message": "Processing completed successfully"
}

Error Response Pattern

{
    "success": false,
    "error": {
        "code": "PROCESSING_ERROR",
        "message": "Failed to process document",
        "details": /* error specifics */
    }
}

File Processing Response

{
    "success": true,
    "file_info": {
        "name": "document.pdf",
        "size": 1024000,
        "pages": 5
    },
    "extracted_data": /* processing results */
}

Flow Examples

Document Processing API

http in → OCR → Document Classifier → format response → http response

File Upload Processing

http in → validate file → PDF Processor → extract data → http response

Error Handling

http in → [processing blocks] → success response → http response

      catch → error response → http response

Multi-step Processing

http in → OCR → Entity Extractor → Template Matcher → compile results → http response

Response Examples

Successful Document Processing

{
  "status": "success",
  "document_info": {
    "pages": 3,
    "text_extracted": true,
    "tables_found": 2
  },
  "extracted_data": {
    "entities": ["John Doe", "ABC Company"],
    "key_values": {
      "total": "$1,500.00",
      "date": "2024-01-15"
    }
  }
}

File Upload Error

{
  "status": "error",
  "message": "File format not supported",
  "supported_formats": ["pdf", "png", "jpg", "tiff"],
  "received_format": "docx"
}

Tips

  • Always include meaningful error messages for debugging
  • Use the debug block before http response to inspect your response data
  • Set appropriate Content-Type headers for different response types
  • Consider response size limits for large processed documents
  • Use proper HTTP caching headers when appropriate

Deployment

The http response block works automatically once your flow is deployed:

  1. Complete your flow: Ensure http in → [processing] → http response chain is connected
  2. Test locally: Use debug blocks to verify response format
  3. Deploy via Flow AI: Deploy your complete flow to make the API available
  4. Test the endpoint: Verify responses using API testing tools

Complete your API workflows by pairing with http in blocks. See Building Flows for deployment instructions.