Trigger comparison: API trigger vs Tracking API vs Omniconnect
Bloomreach Engagement offers multiple trigger mechanisms for different use cases. This guide compares three commonly confused approaches to help you select the best fit for your specific scenario:
- API trigger: Best for broadcasting a single event to many customers at once, such as urgent news or global alerts.
- Tracking API + On event trigger: Ideal for reacting instantly to individual customer actions when your system already sends Bloomreach-ready data.
- Omniconnect + On event trigger: Perfect when you need to transform, clean, or authenticate incoming data before it becomes an event in Bloomreach.
API Trigger
Built for "world events" such as a football goal, price change, or weather alert. A single request sparks a scenario that fans out to the entire qualified audience.
Common examples: "A goal is scored in a football match" or "20M contacts get a push at kickoff."
Rate limiting: Global rate window enforced (1 request every 1-100 seconds, depending on project size). Exceeding it returns HTTP 429.
When to use
- Sports events (goals scored, game start times)
- Price changes or flash sales
- Weather alerts for affected regions
- Breaking news announcements
- System maintenance notifications
When NOT to use
- Individual customer events
- High-frequency events
- Real-time personalization
- Transactional messages
Tracking API + "On event" trigger
Tracking API is meant for real-time, per-customer events—"manipulating customer and event properties."
In a scenario, an "On event" trigger streams exactly one customer each time that event is tracked, letting the journey react immediately (for example, send financing options).
Best when: The external system can already send Bloomreach-ready JSON. No extra middleware needed.
When to use
- Financing applications requiring instant response
- Cart abandonment triggers
- Purchase confirmations
- Account status changes
- Subscription renewals
When NOT to use
- Broadcast scenarios
- Complex data transformation needed
- Third-party webhooks requiring validation
Omniconnect + "On event" trigger
Accepts third-party webhooks directly and lets you rewrite the payload in JavaScript before it becomes an event/attribute.
Added features:
- Built-in logging and retry visibility
- Governance guardrails: up to 5 integrations per account, 400k requests/month each
Ideal when: The inbound call contains extra nesting, different field names, or requires HMAC verification—things the plain Tracking API won't handle.
When to use
- Third-party system integrations with different data formats
- Webhooks requiring HMAC verification
- Payloads with nested data structures
- Custom authentication requirements
- Integration logging and monitoring needs
When NOT to use
- Simple, clean data (use Tracking API instead)
- Broadcast scenarios (use API Trigger instead)
- Real-time critical events (transformation adds latency)
Quick decision chart
| Use case | Recommended path |
|---|---|
| Kick-off at 7 pm; message 20M fans | API Trigger |
| Customer applies for financing (payload already clean) → trigger scenario for Customer | Tracking API + "On event" |
| Customer applies for financing (payload needs mapping or signing) → trigger scenario for Customer | Omniconnect + "On event" |
Detailed comparison table
| Feature | API Trigger | Tracking API + "On event" | Omniconnect + "On event" |
|---|---|---|---|
| Use case | Send urgent weather alerts to all subscribers in affected regions | Send financing options when customer applies for credit | Process financing applications from ChargeAfter with custom payload transformation |
| Trigger source | Severe weather detection system | Customer financing application on website | ChargeAfter webhook with custom data format |
| Input data | Weather alert type, impacted regions, severity level, expiration time | Customer ID, application amount, credit score, product category | Raw ChargeAfter payload with nested data and HMAC signature |
| Customer message | SMS: "Severe thunderstorm warning for your area. Take shelter immediately." | Email: "Your financing options for $2,500 purchase" | Email: "Your financing application has been processed" |
| API payload example | { "alert_type": "severe_thunderstorm", "regions": ["NYC", "NJ", "CT"], "severity": "high", "expires_at": "2024-01-15T20:00:00Z" } | { "customer_id": "12345", "event": "financing_application", "amount": 2500, "credit_score": 720, "product_category": "electronics" } | { "chargeafter_data": { "application_id": "CA123", "customer": { "email": "[email protected]", "amount": 2500 } }, "signature": "hmac_hash_here" } |
| Setup configuration | API Trigger settings: Rate limit 60 seconds, authentication configured | Tracking API endpoint configured with authentication | Omniconnect webhook endpoint with JavaScript transformation |
| Scenario setup | API Trigger → Filter by region → Send SMS | On Event: financing_application → Send personalized email | Omniconnect → Transform payload → On Event: financing_processed → Send email |
| Expected outcome | All subscribers in NYC, NJ, CT receive SMS within 30 seconds | Customer receives financing options email immediately | Customer receives confirmation email after payload transformation |
| Rate limits | Global rate window (1-100 seconds depending on project size) | No global limits, per-customer processing | 5 integrations per account, 400,000 requests/month each |
| Technical complexity | Simple setup, complex rate limit management | Medium complexity, requires Bloomreach-ready JSON | High complexity, requires JavaScript transformation |
| Data processing | Broadcast events (one-to-many) | Individual customer events (one-to-one) | Individual customer events with transformation (one-to-one + processing) |
Updated about 20 hours ago