How to Reach an External CRM's REST API to Sync Leads via the HTTP Connector

Capture a new lead with a Webhook trigger, shape it with a Transform node, and push it into a CRM that has no native Spojit tile by calling its REST API directly with the http connector, complete with retry and fallback handling.

What This Integration Does

Plenty of sales teams run a CRM that does not have a dedicated tile in Spojit. That does not mean you are stuck. Spojit is not limited to its native connectors: the http connector can call any external REST API over HTTPS, so you can post new leads straight into your CRM's /leads endpoint using nothing more than the URL, your API key, and a JSON body. This tutorial wires a lead-capture form or marketing tool to your CRM so that every new lead lands as a created record automatically, with no copy-paste and no missed follow-ups.

The workflow runs on a Webhook trigger: your form or marketing platform sends an HTTP POST to the workflow's URL, Spojit parses the JSON body, a Transform node reshapes it into the exact field names your CRM expects, and a Connector node on the http connector posts it to https://api.yourcrm.com/v1/leads. A Condition node inspects the HTTP status code: a 2xx response means success, and a json node parses the created record id out of the response body; a non-2xx response routes into a retry-and-fallback branch so transient failures do not silently lose a lead. Each inbound POST produces one execution, and re-runs are idempotent only to the extent your CRM dedupes, so the Tips section covers guarding against duplicates.

Prerequisites

A Webhook signing connection so the incoming POST can be verified. Create one under Connections using the Custom or Spojit scheme. See the related guide on setting up a webhook connection.
Your CRM's REST API base URL (for example https://api.yourcrm.com/v1) and the exact field names its create lead endpoint expects.
An API key or token for your CRM with permission to create lead records. You will pass it in the Authorization header.
A sample of the payload your form or marketing tool sends, so you can map its fields correctly.
No native CRM connector is required or invented here. You reach the CRM purely through the http connector's REST tools.

Step 1: Capture the lead with a Webhook trigger

Add a Trigger node and set its type to Webhook. Choose the signing connection you created in the prerequisites so Spojit can verify each request via HMAC. Copy the generated workflow URL and configure your lead-capture form or marketing platform to POST to it. When a lead arrives, the trigger output is the parsed JSON body, available downstream as {{ trigger.body }} (or the individual fields it contains). The trigger returns 202 with an executionId to the caller, so this workflow runs asynchronously. A typical inbound body looks like:

{
  "first_name": "Dana",
  "last_name": "Okafor",
  "email": "dana@example.com",
  "company": "Northwind Retail",
  "phone": "+61 400 000 000",
  "source": "website-contact-form"
}

Step 2: Shape the payload with a Transform node

Add a Transform node to map the inbound fields onto the exact shape your CRM's REST endpoint expects. CRMs rarely use the same field names as your form, so this is where you rename, combine, or default values. For example, your CRM might want a single name field and a nested attributes object. Produce an output such as:

{
  "name": "{{ trigger.body.first_name }} {{ trigger.body.last_name }}",
  "email": "{{ trigger.body.email }}",
  "company": "{{ trigger.body.company }}",
  "phone": "{{ trigger.body.phone }}",
  "lead_source": "{{ trigger.body.source }}",
  "status": "new"
}

Save the output to a variable such as lead_payload so the next step can reference it as {{ lead_payload }}. If you need more complex logic, such as normalising a phone number or signing a value, you can add a Connector node on the code connector using execute-javascript before this step, but for straight field mapping the Transform node is enough.

Step 3: Post the lead to the CRM with the HTTP connector

Add a Connector node, choose the http connector, and set it to Direct mode so the call is deterministic and costs no AI credits. Pick the http-post tool. Configure the fields:

url: https://api.yourcrm.com/v1/leads
headers: include Authorization: Bearer YOUR_API_KEY and Content-Type: application/json. Store the key in your Webhook or API-key connection rather than hardcoding it in plain text where possible.
body: {{ lead_payload }} from the previous step.

The http-post tool returns the response status code, headers, and body. Save the result to a variable such as crm_response. If your CRM uses a non-standard verb or you need finer control over the request shape, the http connector also exposes http-put, http-patch, and the general-purpose http-request tool.

Step 4: Branch on the HTTP status with a Condition node

Add a Condition node to check whether the call succeeded. Test the status code from the previous step, for example {{ crm_response.status }} is greater than or equal to 200 and less than 300. Route the true branch onward to parse the created record, and route the false branch into the retry-and-fallback handling in the next step. Keeping the success and failure paths separate means a transient 500 from the CRM never gets treated as a created lead.

Step 5: Parse the created record id with a json node

On the success branch, add a Connector node on the json connector in Direct mode. Use the get tool to pull the new record id out of the response body. Set the data input to {{ crm_response.body }} and the path to wherever your CRM nests the id, for example id or data.lead.id. Save the result to lead_id. If you prefer to validate the whole body first, the json connector also offers parse and validate. You now have a clean {{ lead_id }} you can log, send in a confirmation, or pass to a downstream step.

Step 6: Handle non-2xx responses with retry and fallback

Spojit's built-in retry and error handling let a step automatically re-attempt on failure before the branch is considered failed. On the http connector node from Step 3, enable retries (for example 3 attempts with a backoff) so brief network blips or rate limits recover on their own. For responses that still fail after retries, the false branch of your Condition node is your fallback path. A robust fallback does two things:

Notify a human so the lead is not lost. Add a Send Email node that emails your sales operations inbox with the lead details from {{ lead_payload }} and the failing status {{ crm_response.status }} and body. This uses Spojit's built-in mail service and needs no connection.
Optionally retry against a secondary endpoint or queue the lead for later by writing it somewhere durable. For more advanced patterns, see the related article on handling errors and building fallback workflows.

Because the trigger already returned 202 to the caller, the fallback runs server-side without blocking the form, so the customer never sees an error even when the CRM is temporarily down.

Tips

Use Direct mode on the http and json nodes. These calls are predictable single-tool actions, so there is no reason to spend AI credits on Agent mode here.
Guard against duplicate leads. If a form retries or the webhook fires twice, your CRM may create two records. Many CRMs support an upsert or a dedup-by-email key; map your Transform output accordingly, or enable the trigger's opt-in dedup via an event-id header.
Keep the API key out of the request body and version history. Store it in a connection and reference it from the Authorization header rather than pasting it into the node every time.
Let Miraxa, the intelligent layer across your automation, scaffold the skeleton. Ask it: "Add a Condition node that checks if {{ crm_response.status }} is under 300 and connect the true branch to a json node that gets id from {{ crm_response.body }}." Then fine-tune in the properties panel.

Common Pitfalls

Inventing a connector. There is no "Salesforce connector" or "HubSpot connector" to add for a system without a native tile. Always reach it as "your CRM's REST API via the http connector" with http-post. Fabricating a named connector will not work.
Treating any response as success. Some APIs return 200 with an error object in the body. After the status check, inspect {{ crm_response.body }} for an error field before parsing the id.
Wrong content type. If the CRM rejects the request, confirm you set Content-Type: application/json and that your Transform output is valid JSON, not a stringified blob.
Missing or expired token. A 401 or 403 from the CRM almost always means the Authorization header is wrong or the key has rotated. Surface these in the fallback email so they get fixed fast.

Testing

Before pointing live traffic at the workflow, validate on a small scope. Point a single test form submission (or use a tool like a manual POST) at the webhook URL with one fake lead, then open the execution in your run history. Confirm the Transform output matches your CRM's field names, the http-post node returned a 2xx, the Condition node took the true branch, and the json node extracted a real lead_id. Then deliberately break it: send a payload your CRM will reject (for example a malformed email) and confirm the false branch fires, retries exhaust, and the fallback Send Email lands in your inbox. Only after both the happy path and the failure path behave correctly should you connect your production lead source.