Pabbly Connect integration
Outgoing events use a versioned JSON schema (v1.0) with no names or emails: Pabbly fetches personal data only through the authenticated API, and only for an eligible action.
PABBLY_API_KEY is empty: set it in the Environment tab to enable the API
Authentication
Send X-API-Key: <PABBLY_API_KEY> or Authorization: Bearer …. Add Idempotency-Key on POSTs: a retry with the same key returns the first response and repeats nothing. Outgoing events carry X-CRM-Event-Id; when PABBLY_WEBHOOK_SECRET is set they are signed with X-CRM-Signature: sha256=HMAC(body).
| Method | Path | Purpose |
|---|---|---|
| GET | /api/v1/leads/:id/eligibility?followup_id= | Lead automation eligibility: stage, status, communication basis, sequence version, per-action decision |
| GET | /api/v1/due-followups | Currently due, still-eligible customer/partner actions (poll from a scheduled workflow) |
| GET | /api/v1/followups/:id | Authorized follow-up info with rendered template and recipient (only while eligible) |
| POST | /api/v1/followups/:id/reserve | Re-checks everything and reserves the action; returns a token. Send only if authorized is true |
| POST | /api/v1/followups/:id/confirm | { token, result } confirm delivery. Repeating it is safe |
| POST | /api/v1/followups/:id/fail | { token, error } record a failure (visible and retryable in the CRM) |
| POST | /api/v1/leads/:id/activities | { kind: email|call|note|automation, summary } |
| POST | /api/v1/leads/:id/tasks | { title, due_at, assignee_id } internal task |
| POST | /api/v1/leads/:id/response | { channel, summary, message_id } record a verified customer reply; cancels customer follow-ups and pauses |
| POST | /api/v1/leads/:id/automation | { action: pause|resume, reason } |
Events
- lead.created
- lead.stage_changed
- lead.owner_assigned
- lead.followup_due
- lead.followup_cancelled
- lead.customer_responded
- lead.qualification_incomplete
- lead.sales_ready
- lead.handover_requested
- lead.handover_approved
- lead.handover_completed
Example payload
{
"schema_version": "1.0",
"event_id": "evt_6f1c…",
"event": "lead.followup_due",
"occurred_at": "2026-10-16T09:00:00.000Z",
"lead": { "id": 3, "ref": "TL-2603", "stage": "Contacting", "owner": { "id": 3, "name": "Elena Rossi" },
"priority": "high", "automation_status": "active", "sequence_version": 2, "language": "en", "country": "United Kingdom" },
"actions": { "followup_id": 7, "step": 1, "action_type": "customer_email", "template_key": "followup_1",
"planned_at": "2026-10-15T08:00:00.000Z", "idempotency_key": "3:3:2" }
}Workflows to build in Pabbly Connect
- A · New Lead: lead.created → notify owner → GET followup → POST reserve → send acknowledgment → POST confirm / fail.
- B · Follow-up: lead.followup_due (or schedule GET /due-followups) → reserve → send only if authorized → confirm or fail.
- C · Customer response: verified reply → POST response → notify owner.
- D · Qualification reminder: lead.qualification_incomplete → internal reminder or information request → record result.
- E · Sales Ready: lead.sales_ready → notify reviewer; approval happens in the CRM.
- F · Partner handover: lead.handover_completed → reserve partner action → send partner notification → confirm.
A delay inside Pabbly never overrides the CRM: the reserve call re-evaluates stage, status, basis and sequence version at send time.