Skip to main content

Choose a webhook surface

Qanivo uses “webhook” for several different contracts. Select the surface by direction and ownership before writing code.

SurfaceDirectionIntegrator roleQanivo route/ownershipAuthentication/signingRetry modelStatus
Provider WebhookProvider → QanivoProvider connection operatorProvider-specific worker ingressProvider-specific verification before normalizationProvider/provider-worker acknowledgement and redelivery rulesprovider-limited
Qanivo Event HookQanivo → subscriberExternal Consumer administrator/api/external/v1 subscription and delivery servicesScoped External Consumer identity plus Qanivo signatureDelivery attempts, bounded retries, disablementsupported
Workflow Webhook ActionWorkflow → targetWorkspace Workflow designerGoverned Workflow action dispatcherWorkspace authorization; current handler adds no Qanivo signatureWorkflow attempt/retry and terminal failurenot-verified
Lead DeliveryQanivo → destinationLead delivery administratorLead Delivery Subscription/attempt ownershipCurrent URL policy accepts HTTP/HTTPS; worker adds lead-delivery signature when configuredIndependent bounded attempts and terminal outcomesupported

These surfaces do not share credentials, payload ownership, or success semantics. A Provider Webhook is inbound provider traffic; an Event Hook and Lead Delivery are outbound Qanivo deliveries; a Workflow Webhook Action is one governed step in a Workflow run.

Start here

Common rules

  • Resolve the trusted Workspace/Connection/External Consumer scope from authenticated context, never from a payload-selected identifier.
  • Validate authenticity, replay, schema, bounds, and authorization before accepting or delivering data.
  • Treat normalized status and delivery outcome as explicit values; transport success is not CRM acceptance, conversion, or provider success.
  • Keep secrets, raw provider payloads, signing material, and internal topology out of public responses and logs.