Skip to content

Webhooks & Custom Integrations

Updated

On this page39

Overview#

Webhooks are the backbone of custom integrations in AutomateNexus CRM. They allow the CRM to send real-time HTTP notifications to external systems whenever specific events occur, such as a new contact being created, a deal changing stages, or a form being submitted. Whether you are building a custom application, integrating with an in-house system, or connecting to a service that does not have a native AutomateNexus CRM integration, webhooks provide the flexibility to make it happen. This guide covers everything from creating webhooks to understanding payload formats, verifying signed deliveries, and building custom integrations with the AutomateNexus CRM API.

Prerequisites#

Before setting up webhooks and custom integrations, ensure you have:

  • An active AutomateNexus CRM account with permission to change your organization's settings.
  • A receiving endpoint (server, serverless function, or automation platform) that can accept HTTP POST requests over HTTPS.
  • Basic understanding of HTTP, JSON, and REST APIs.
  • Your AutomateNexus CRM API key for making API calls back to the CRM (generated under Settings → Integrations → Developer → API keys, or under Settings → API keys).
  1. Log in to your AutomateNexus CRM dashboard.
  2. In the sidebar, under Administration, click Integrations.
  3. Choose Developer in the left menu of the Integrations page.
  4. Scroll to the Webhooks heading. It holds the Create webhook card and, below it, your Active webhooks.

Creating a Webhook#

Step-by-Step Webhook Creation#

  1. Navigate to Settings → Integrations → Developer → Webhooks.
  2. In the Create webhook card, fill in:
    • Name: A descriptive name for the webhook (e.g., "Zapier — new leads", "Deal stage to Slack").
    • Endpoint URL: The URL where webhook payloads will be sent. This must be a publicly accessible HTTPS URL. Examples: https://yourapp.com/webhooks/automatenexus, https://hooks.zapier.com/hooks/catch/..., or a serverless function URL. It works with Zapier, Make, n8n, Pabbly, or any HTTPS endpoint.
    • Events: Tick one or more events from the groups listed below. At least one is required.
    • Description: Optional notes about this webhook.
  3. Click Create webhook.
  4. A Webhook signing secret dialog opens. Copy the secret now: it is stored encrypted and cannot be shown again. Click Done.

Every payload is sent as a JSON POST, and a new webhook is active as soon as it is created.

Available Event Types#

AutomateNexus CRM fires the following webhook events, organized by group in the event picker:

Contacts#

  • contact.created — A contact is created.
  • contact.updated — A contact is updated.

Deals#

  • deal.created — A deal is created.
  • deal.updated — A deal is updated.
  • deal.stage_changed — A deal moves to a different stage.

Customers#

  • customer.created — A customer is created.
  • customer.updated — A customer is updated.

Companies#

  • company.created — A company is created.
  • company.updated — A company is updated.

Tasks#

  • task.created — A task is created.
  • task.updated — A task is updated.

Forms#

  • form.submitted — A form receives a submission.

Webhook Payload Format#

All webhook payloads are sent as JSON with a consistent structure:

{
  "event": "contact.created",
  "occurred_at": "2026-09-24T14:30:00.000Z",
  "organization_id": "…",
  "object": "contacts",
  "data": { … the full record as it now stands … },
  "previous": null
}

Payload Fields Explained#

  • event: The event type string that triggered the webhook.
  • occurred_at: The timestamp of when the event occurred, in UTC.
  • organization_id: Your AutomateNexus CRM organization identifier.
  • object: The kind of record the event is about (for example contacts, deals, tasks).
  • data: The full record associated with the event. Its fields vary with the object type.
  • previous: For update events, the record as it was before the change; null for created events. For deal.stage_changed, compare the stage in data with the stage in previous.

A test delivery uses the event webhook.test with a short message in data.

Securing Webhooks#

Webhook Signing Secret#

Every webhook has a signing secret, generated server-side when you create it and shown once. To verify that webhook payloads are genuinely from AutomateNexus CRM and have not been tampered with, check the signature on each delivery:

  1. Each delivery carries an X-Webhook-Signature header of the form t=<unix seconds>,v1=<signature>, along with X-Webhook-Id, X-Webhook-Event and X-Webhook-Timestamp headers.
  2. The signature is the hex HMAC-SHA256, keyed with your signing secret, of the string {t}.{raw request body}.

Verifying Webhook Signatures#

In your receiving application, take t from the header, compute the HMAC-SHA256 of t, a period, and the raw request body using your signing secret, and compare it with v1. If they match, the payload is authentic. A verification example is on the API documentation page linked from Settings → Integrations → Developer.

Rotating the Secret#

To replace a secret, click the key button on the webhook in Active webhooks and confirm. The current secret stops working immediately and the new one is shown once in a New signing secret dialog.

Retry Policy and Error Handling#

Automatic Retries#

If a webhook delivery fails (HTTP status code outside the 2xx range, or a connection timeout), AutomateNexus CRM retries the delivery:

  • Retry schedule: 1 minute, 5 minutes and 30 minutes after the failed attempt.
  • Maximum attempts: 4 per delivery (the initial attempt plus 3 retries).
  • Timeout: Each attempt has a 10-second timeout. If your server does not respond within 10 seconds, the attempt is considered failed.

A webhook whose recent deliveries keep failing shows a count of consecutive failures in the list, along with the time of its last success and last failure.

Monitoring Webhook Deliveries#

  1. Navigate to Settings → Integrations → Developer → Webhooks.
  2. Click Deliveries on a webhook to open its Delivery log. It shows the latest 50 deliveries; rows older than 30 days are pruned automatically.
  3. Each delivery shows:
    • The event type and its status: Delivered, Failed or Pending.
    • The HTTP response status code and the response time in milliseconds.
    • The attempt count out of the maximum, and for a pending delivery when the next retry is due.
    • Expanded, the last error, each attempt with its result and the first part of the response body, and the payload that was sent.
  4. Use the delivery log to debug failed deliveries and identify issues with your receiving endpoint.

Custom Integrations with the API#

AutomateNexus CRM REST API#

For building bidirectional custom integrations, use the AutomateNexus CRM REST API alongside webhooks. While webhooks push data out of the CRM in real time, the API allows you to pull data and push changes back into the CRM. Your API base URL is shown under Settings → Integrations → Developer → API endpoint, with a copy button and a Docs button that opens the API documentation.

API Authentication#

All API requests require authentication via the Authorization header, using a key from Settings → Integrations → Developer → API keys:

Authorization: Bearer YOUR_API_KEY

Common API Endpoints#

Append the resource to your base URL. Each resource supports GET (list, with limit and offset pagination), POST (create), and, with an id in the path, GET, PUT and DELETE:

  • /contacts — Contacts.
  • /customers — Customers.
  • /deals — Deals, with their pipeline and stage.
  • /tasks — Tasks.
  • /notes — Notes.
  • /invoices — Invoices.
  • /signatures — E-signature requests.
  • /analytics, /export, /bulk, /search and /schema — Analytics, data export, bulk operations, search across records, and the API schema.

See API Overview & Authentication for the full reference.

API Rate Limits#

  • 120 requests per minute per API key.
  • When the limit is exceeded the API responds with HTTP 429 and a Retry-After header.
  • Every response includes X-RateLimit-Limit and X-RateLimit-Remaining headers.

Building a Custom Integration#

A typical custom integration pattern combines webhooks and API calls:

  1. Set up a webhook in AutomateNexus CRM to receive events when specific CRM actions occur.
  2. Process the webhook payload in your application. Extract the relevant data from the JSON payload.
  3. Perform your custom logic. This could be updating an external system, running calculations, sending notifications, or triggering other processes.
  4. Call the API to update AutomateNexus CRM if needed. For example, after processing a webhook for a new contact, you might enrich the contact with additional data from an external source and update the contact record via the API.

Testing Webhooks#

Using the Built-in Test Feature#

  1. Navigate to Settings → Integrations → Developer → Webhooks.
  2. Click Test on the webhook you want to test.
  3. AutomateNexus CRM sends a real, signed webhook.test delivery to your endpoint and reports the HTTP status and response time it got back.
  4. Open Deliveries to see the test in the delivery log.

Testing with Request Inspection Tools#

If you do not have a receiving server ready, use request inspection tools to test webhook payloads:

  • webhook.site: Provides a temporary URL that captures and displays incoming webhook requests. Copy the URL and use it as your webhook endpoint for testing.
  • RequestBin: Similar to webhook.site, provides a temporary endpoint for inspecting payloads.
  • ngrok: Creates a secure tunnel to your local development server, allowing AutomateNexus CRM to send webhooks to your local machine during development.

End-to-End Testing#

  1. Create a test webhook pointing to your receiving endpoint.
  2. Select all event types you plan to use.
  3. Perform the corresponding actions in AutomateNexus CRM (create a contact, update a deal, submit a form, etc.).
  4. Verify each event is delivered to your endpoint with the correct payload.
  5. Test error handling by temporarily making your endpoint return a 500 error, then verify retries occur as expected.
  6. Test signature verification by comparing the computed HMAC against the X-Webhook-Signature header.

Troubleshooting#

Webhook Not Firing#

  • Verify the webhook's switch is on: it shows Active in the list.
  • Check that the correct events are selected for the webhook.
  • Confirm the action you performed in the CRM matches one of the selected event types.
  • Review the delivery log for any error messages.

Receiving 4xx Errors#

  • 400 Bad Request: Your receiving server is rejecting the payload format. Ensure it accepts JSON POST requests.
  • 401 Unauthorized: Your receiving server requires authentication that the webhook does not carry. Accept the delivery on an endpoint that verifies the X-Webhook-Signature header instead.
  • 403 Forbidden: Your server is blocking the request. Check firewall rules or CORS settings.
  • 404 Not Found: The endpoint URL is incorrect. Verify the URL path is correct and the server is running.

Receiving 5xx Errors#

  • Your receiving server is experiencing an internal error. Check the server logs for error details.
  • Ensure your server can handle the payload and respond within the 10-second timeout.
  • AutomateNexus CRM automatically retries failed deliveries according to the retry policy.

Payloads Not Matching Expected Format#

  • Check the event type to ensure you are receiving the correct event (e.g., contact.created vs. contact.updated).
  • Open the delivery in the delivery log to see the exact payload that was sent.

Signature Verification Failing#

  • Ensure you are using the raw request body (not parsed JSON) when computing the HMAC, prefixed with the timestamp and a period.
  • Verify the signing secret matches exactly; if you rotated it, the old secret no longer works.
  • Check that you are using HMAC-SHA256 and comparing against the v1 value in hex.

Too Many Webhook Events#

  • If you are receiving more events than expected, narrow down the selected events to only those you need, or create separate webhooks per event.
  • Consider batching webhook processing in your application to handle high-volume events efficiently.

Was this page helpful?