Pattern 1: The lead router
Flow: website form / webinar / Inbound tool → middleware (Zapier, serverless function) → PersistIQ API creates prospect → adds to campaign.
Watch for: deduplication by email before create; filling at least the Snippet field with something real; excluding existing opted-out contacts.
Pattern 2: Reply-to-Slack
Flow: webhook (replied) → function → Slack message with prospect link.
Watch for: idempotency (retries duplicate alerts); include the prospect URL in the message so the SDR lands on the record in one click.
Pattern 3: CRM status mirror
Flow: webhook events (replied / opted out / bounced) → write status to your CRM (native Salesforce/Pipedrive/Copper sync, or API calls to something else).
Watch for: mapping PersistIQ states to CRM stages deliberately — don't create a stage per event.
Pattern 4: The analytics pipeline
Flow: webhooks → queue → warehouse → BI tool.
Watch for: store raw event payloads; derived tables can be rebuilt, raw events can't.
Pattern 5: The nightly upsert
Flow: source of truth (data warehouse, Sheets, Airtable) → scheduled job → API upsert prospects → attach to campaign.
Watch for: making the job resumable; a failed 5,000-row sync shouldn't start from scratch or double-send.
General rules
- One system of record per data type; everything else syncs from it.
- Log every API error with context — "409 on prospect create" is useless without the payload.
- Test the failure paths, not just the happy path: what happens when the API is down during your nightly sync?