Connector-specific delivery behavior
All connectors use the same delivery guarantees, retry policies, audit logging, and recovery mechanisms described in Delivery retries and recovery. The following sections highlight the behaviors that are unique to each supported connector type.
Choose the connector that best aligns with your integration architecture, operational requirements, and cloud ecosystem.
HTTP/Webhook
Use the HTTP/Webhook connector when you want the Pismo platform to deliver events directly to an HTTPS endpoint that you manage.
Events are delivered individually using HTTPS POST requests. To secure inbound traffic, the connector supports JWT-based authentication and optional mutual TLS (mTLS).
Figure 3. HTTP response handling sequence
Response handling
Your endpoint confirms successful event receipt by returning an HTTP status code in the 2xx range (200-299).
Any other response, including redirects, is treated as a delivery failure and triggers automatic retry processing.
| Response | Interpretation | What happens next |
|---|---|---|
| 200-299 (2xx) | Delivery successful | Event recorded as successfully delivered |
| 300-399 (3xx) | Delivery failed | Event re-queued, response body logged |
| 400-499 (4xx) | Delivery failed | Event re-queued, response body logged |
| 500-599 (5xx) | Delivery failed | Event re-queued, error details logged |
| Connector error | Delivery failed | Event re-queued, error details logged |
Your endpoint must return a 2xx status code to acknowledge successful receipt of an event. Redirects (3xx responses) are not supported and are treated as delivery failures.
Connector characteristics
| Aspect | Detail |
|---|---|
| Delivery model | One event per HTTPS request |
| Timeout per request | 10 seconds |
| Retry behavior | Up to 10 delivery attempts with exponential backoff (~30 min) |
| On failure | Automatically re-queued by the platform |
| Authentication | JWT (configurable expiry, default 1 hour) + optional mTLS |
| Transport security | TLS 1.2 or later |
| Encryption | TLS 1.2+ mandatory, optional payload encryption (AES + RSA) |
Connector considerations
Design your endpoint to return a 2xx response as quickly as possible. Process events asynchronously when long-running operations are required. Ensure your application can safely handle duplicate events because at-least-once delivery may result in redelivery.
AWS SNS
Use AWS SNS when you need to distribute events to multiple AWS subscribers or downstream services.
The Fanout service publishes events in batches and supports partial-failure detection at the individual message level.
AWS Connector characteristics
| Aspect | Detail |
|---|---|
| Delivery method | Batch publish (up to 10 messages per call) |
| Partial-failure handling | Supported; per entry failure detection |
| SDK retry behavior | AWS SDK default retry policy applies |
| Batch failure handling | Failed events are re-queued for retry |
AWS SNS considerations
- Verify subscriber health and downstream processing capacity.
- Monitor SNS delivery subscriptions independently of Fanout delivery status.
AWS EventBridge
Use AWS EventBridge when integrating Pismo events into event-driven AWS architectures.
Events are published in batches and support per-event failure detection.
AWS Connector characteristics
| Aspect | Detail |
|---|---|
| Delivery method | Batch publish |
| Partial-failure handling | Supported; per entry failure detection |
| SDK retry behavior | AWS SDK default retry policy applies |
| Batch failure handling | All events in batch marked failed, then re-queued |
AWS considerations
- Use EventBridge routing rules to distribute events to downstream services.
- Monitor EventBridge targets to ensure successful event consumption.
Google Cloud pub/sub
Use Google Cloud Pub/Sub when integrating with Google Cloud services and event-processing workloads.
The connector publishes events individually while the client library manages internal batching and optimizations.
Google Cloud connector characteristics
| Aspect | Detail |
|---|---|
| Delivery method | Individual publish per event (client auto-batches internally) |
| Partial failure | Per-event; failure on one does not block others |
| SDK retry | GCP client default retry policy applies |
Google Cloud pub/sub considerations
- A failure for one event does not prevent the delivery of other events.
- Monitor subscription backlogs and message processing latency.
Azure service bus
Use Azure Service Bus when integrating with Azure-based messaging and event-processing solutions.
Events are delivered in batches. Each batch either succeeds or fails as a unit.
| Aspect | Detail |
|---|---|
| Delivery method | Batch send (entire batch succeeds or fails together) |
| SDK retry behavior | Two retries, 100 ms interval (configurable) |
| Connection management | Cached for 9 minutes to reduce connection overhead |
Azure service bus considerations
- Batch delivery behavior means all events in a batch share the same delivery outcome.
- Monitor queue and topic health to identify downstream processing issues.
Connector comparison
The following table summarizes the key delivery characteristics of each connector.
| Connector | Delivery Model | Partial Failure Support | Retry Management |
|---|---|---|---|
| HTTP/Webhook | Individual event | N/A | Fanout service |
| AWS SNS | Batch | Yes | AWS SDK |
| AWS EventBridge | Batch | Yes | AWS SDK |
| Google Cloud Pub/Sub | Individual event | Yes | GCP client library |
| Azure Service Bus | Batch | No (batch-level outcome) | Azure SDK |
Updated about 13 hours ago