Firehose

Firehose Multi-Service Configuration

Overview

Each flow is separately configured to use the firehose. This API allows firehose configuration to be tested before it is set on a flow.

The Firehose feature supports multiple cloud storage services for event data export. This document describes the configuration options for both AWS S3 and Azure Blob Storage services.

Configuration Structure

Legacy Configuration (Backward Compatible)

For existing flows, the legacy configuration continues to work:

{
  "firehose": {
    "enabled": true,
    "credential_id": "507f1f77bcf86cd799439011",
    "bucket": "my-s3-bucket",
    "prefix": "events/production"
  }
}

New Service-Based Configuration

The new service-based configuration allows multiple cloud storage providers:

{
  "firehose": {
    "enabled": true,
    "services": {
      "aws": {
        "enabled": true,
        "credential_id": "507f1f77bcf86cd799439011",
        "bucket": "my-s3-bucket",
        "prefix": "events/aws"
      },
      "azure": {
        "enabled": true,
        "credential_id": "507f1f77bcf86cd799439012", 
        "bucket": "my-azure-container",
        "prefix": "events/azure"
      }
    }
  }
}

Credential Validation

AWS S3 Validation

The /firehose endpoint validates AWS credentials by:

  1. Creating a test file with unique name: leadconduit_verification_[flow_id_]YYYYMMDDHHMMSSMS.txt
  2. Uploading it to the specified bucket (with optional prefix) when verification_file=true (default)
  3. Alternatively, validating bucket access without creating file when verification_file=false
  4. Returning the S3 response with ETag or validation confirmation

Example Requests:

Basic validation (creates file):

curl -X GET "https://app.leadconduit.com/firehose?service=aws&access_key_id=AKIA...&secret_access_key=wJal...&bucket=my-bucket&prefix=test"

With flow ID (includes flow identifier in filename):

curl -X GET "https://app.leadconduit.com/firehose?service=aws&access_key_id=AKIA...&secret_access_key=wJal...&bucket=my-bucket&flow_id=507f1f77bcf86cd799439011"

Validation only (no file created):

curl -X GET "https://app.leadconduit.com/firehose?service=aws&access_key_id=AKIA...&secret_access_key=wJal...&bucket=my-bucket&verification_file=false"

Example Responses:

File created:

{
  "validated": true,
  "verification_file": true
}

Validation only:

{
  "validated": true,
  "verification_file": false
}

Azure Blob Storage Validation

The /firehose endpoint validates Azure credentials by:

  1. Creating a BlobServiceClient from the connection string
  2. Checking if the specified container exists and is accessible
  3. Optionally creating verification file based on verification_file parameter
  4. Returning container validation information

Example Request:

curl -X GET "https://app.leadconduit.com/firehose?service=azure&connection_string=DefaultEndpointsProtocol=https;AccountName=test;AccountKey=key;EndpointSuffix=core.windows.net&bucket=my-container"

Example Responses:

With verification file:

{
  "validated": true,
  "verification_file": true
}

Validation only (verification_file=false):

{
  "validated": true,
  "verification_file": false
}

Event Processing

Single Service Configuration

When only one service is configured, events are sent to that service. If the service fails, events are spooled for retry.

Multi-Service Configuration

When multiple services are configured:

  1. Each enabled service receives the event independently
  2. If a service fails, it generates its own spool message for retry
  3. Each service can have different bucket/container and prefix configurations

Spooling and Retry

  • Each service failure generates a separate SQS message for retry
  • Spooled events contain service-specific metadata (bucket, prefix, credentials)
  • The unspooler processes each service's failed events independently
  • File-based spooling creates separate paths for each service configuration

Migration Guide

From Legacy to Service-Based Configuration

  1. Keep existing configuration: Legacy configuration continues to work
  2. Add services object: Gradually migrate to service-based configuration
  3. Test thoroughly: Validate both configurations work as expected

Example migration:

Before:

{
  "firehose": {
    "enabled": true,
    "credential_id": "507f1f77bcf86cd799439011",
    "bucket": "my-bucket"
  }
}

After:

{
  "firehose": {
    "enabled": true,
    "services": {
      "aws": {
        "enabled": true,
        "credential_id": "507f1f77bcf86cd799439011",
        "bucket": "my-bucket"
      }
    }
  }
}

Test firehose's ability to write to AWS S3 or Azure Blob Storage

The /firehose resource is used to validate cloud storage credentials and test write access to a specified bucket/container.

AWS S3 Validation:

  • Creates a test file with unique name leadconduit_verification_[flow_id_]YYYYMMDDHHMMSSMS.txt
  • File location: <prefix>/filename (if prefix provided) or filename (root of bucket)
  • Returns S3 putObject response with ETag on success
  • Can validate credentials without creating file when verification_file=false

Azure Blob Storage Validation:

  • Validates credentials by checking container existence and access permissions
  • Optionally creates verification file based on verification_file parameter
  • Returns container validation information on success

Required Parameters:

  • For AWS: access_key_id, secret_access_key, bucket
  • For Azure: connection_string, bucket (container name)
  • The service parameter determines which validation method is used

Optional Parameters:

  • flow_id: Include flow ID in verification filename for better tracking
  • verification_file: Control whether verification file is created (default: true)
SecurityAPIKey
Request
query Parameters
service
string
Default: "aws"

Cloud service provider. Defaults to 'aws' if not specified.

Enum: "aws" "azure"
access_key_id
string

AWS Access Key ID for S3 authentication. Required when service is 'aws' or not specified.

secret_access_key
string

AWS Secret Access Key for S3 authentication. Required when service is 'aws' or not specified.

connection_string
string

Azure Storage account connection string for Blob Storage authentication. Required when service is 'azure'.

Example: connection_string=DefaultEndpointsProtocol=https;AccountName=myaccount;AccountKey=mykey;EndpointSuffix=core.windows.net
bucket
required
string [ 3 .. 63 ] characters ^[a-z0-9]([a-z0-9\-]*[a-z0-9])?$

Storage container name. For AWS: S3 bucket name. For Azure: Blob Storage container name.

prefix
string

Optional path prefix for stored files.

  • For AWS: Files will be stored as <prefix>/leadconduit_verification_[flow_id_]YYYYMMDDHHMMSSMS.txt
  • For Azure: Currently not used in validation but stored for future use
flow_id
string

Optional flow identifier to include in verification filename. When provided, filename becomes: leadconduit_verification_{flow_id}_{timestamp}.txt When omitted, filename becomes: leadconduit_verification_{timestamp}.txt

Example: flow_id=507f1f77bcf86cd799439011
verification_file
string
Default: "true"

Whether to create the verification file during validation.

  • true (default): Creates verification file and validates credentials
  • false: Only validates credentials/permissions without creating file For AWS: uses headBucket operation instead of putObject when false For Azure: skips file upload step when false
Enum: "true" "false"
Responses
200

Credentials validation successful

400

Bad Request - Invalid parameters

401

Unauthorized - Authentication failed

404

Not Found - Resource not found

409

Conflict - Resource already exists

422

Missing required parameters

500

Internal Server Error

get/firehose
Request samples
Response samples
application/json

Example response when credentials are valid and verification file is created

{
  • "validated": true,
  • "verification_file": true
}