Documentation Index
Fetch the complete documentation index at: https://docs.linquid.io/llms.txt
Use this file to discover all available pages before exploring further.
Integrations and Automation
Integrations connect Linquid to external systems for data ingestion and event delivery.
Integration lifecycle
For each provider:
- install and authenticate
- configure provider-specific settings
- choose active subscriptions/events
- monitor status (active, paused, error, disconnected)
Provider detail pages typically include:
- connection metadata
- installation owner and timestamps
- provider-specific mapping or field settings
- connect/disconnect controls
Lifecycle state expectations
| State | Operational meaning | Typical operator action |
|---|
| Active | Connected and processing | Monitor health and delivery quality |
| Paused | Temporarily disabled by operator | Resume after maintenance/testing |
| Error | Failing due to credential/config issues | Repair credentials/mapping and re-test |
| Disconnected | Integration removed or invalidated | Reconnect only if still required |
Integration classes supported in operations
Most real-world deployments use a combination of:
- payment and billing providers (for commerce-linked outcomes)
- CRM/revenue systems (for lifecycle and funnel alignment)
- ecommerce systems (for order-based attribution)
- communication destinations (Slack/webhooks/automation systems)
Data-boundary model (what should and should not flow)
Integration payloads should remain purpose-limited.
Expected in-scope data:
- conversion identity and value context required for attribution
- campaign/link/rule identifiers required for routing attribution
- customer identity fields needed for stitching and reporting
- status fields needed for lifecycle transitions (pending/approved/paid/refunded style workflows)
Out-of-scope data that should generally be avoided:
- unrelated customer profile details not needed for attribution
- internal-only finance notes or operator-only comments
- credentials/secrets in payload content
- provider fields with no operational/reporting use in Linquid
Use mapping controls to keep payloads minimal and deterministic.
Integration onboarding checklist
- Define business purpose and expected data flow.
- Use least-privilege credentials in provider.
- Map required fields and event names explicitly.
- Run test events and verify destination behavior.
- Enable only required triggers in production.
Inbound ingestion
Inbound integrations typically supply:
- conversion/order signals
- customer lifecycle changes
- command/event triggers
Common ingestion outcomes:
- creation of conversion records
- update of customer profiles and value trails
- enrichment of analytics dimensions and source attribution
Inbound quality checklist:
- validate provider authentication/authorization
- validate event mapping and field normalization
- validate idempotency/dedup behavior on retries
- validate status transitions for partial or failed events
Inbound troubleshooting patterns
| Symptom | Likely cause | First action |
|---|
| Events missing in conversions | Auth or mapping failure | Validate integration status and field mapping |
| Duplicate conversion records | Missing idempotency key | Verify unique transaction/event IDs |
| Wrong revenue values | Currency/value field mismatch | Validate source payload normalization |
| Customers not stitching | Missing identity fields | Ensure email or external customer ID is sent |
Outbound automation
Outbound workflows can deliver:
- conversion or campaign events
- workspace/link webhook payloads
- notifications to chat/ops systems
Typical automation use cases:
- alerting on conversion spikes or drops
- syncing qualified outcomes to external systems
- partner and program operational notifications
Outbound quality checklist:
- destination URL validity and TLS readiness
- signature verification on receiver side
- retry-safe receiver logic (idempotent processing)
- alerting when delivery failure threshold is reached
Outbound troubleshooting patterns
| Symptom | Likely cause | First action |
|---|
| Destination receives no events | Trigger not enabled or integration paused | Confirm integration state and trigger list |
| Receiver rejects deliveries | Signature verification mismatch | Validate secret and signature routine |
| Duplicate events downstream | Receiver not idempotent | Add dedupe/idempotency handling |
| Delivery delays | Retry backlog or destination latency | Inspect delivery logs and destination health |
Webhook reliability model
Operational practices:
- signed payload verification
- retry and error visibility
- separate test vs production configurations
- periodic secret rotation
Operational hardening checklist:
- test delivery signatures before going live
- ensure receiver idempotency for duplicate deliveries
- monitor failure categories and retry exhaustion
- rotate secrets on a fixed schedule
Provider categories
Common provider classes in Linquid:
- payments and billing providers
- CRM and marketing systems
- ecommerce platforms
- chat/automation destinations
Provider intent matrix
| Provider class | Primary direction | Typical purpose |
|---|
| Payments/billing | inbound | sale/revenue and payment lifecycle ingestion |
| CRM/marketing | both | lead lifecycle sync and campaign attribution alignment |
| Ecommerce | inbound | order/conversion ingestion with customer and value context |
| Chat/automation | outbound | operational notifications and downstream automations |
Production hardening checklist
- Separate test and production destinations.
- Rotate provider and webhook secrets on schedule.
- Maintain runbooks for auth failures and mapping regressions.
- Track integration ownership and on-call responsibility.
- Review destination-side idempotency quarterly.
Production rollout pattern
- Enable provider in test mode first.
- Run synthetic test events through full path.
- Verify analytics/output updates in dashboard.
- Enable only required triggers and mappings.
- Promote to production and monitor first-day delivery/error logs.
Related:
/user-guides/manual/workspace/security-and-compliance/user-guides/manual/data/exports-and-operational-checks/user-guides/manual/ecosystem/workspace-integrations-reference/user-guides/manual/ecosystem/provider-setup-playbooks
