Vehicle Onboarding Workflow in Make.com: Webhook RC to HubSpot Deals

Vehicle financing and leasing onboarding usually starts when a partner system POSTs an applicant packet. This Make.com scenario exposes a Custom webhook, extracts Indian RC data with Cryvis, creates or updates a HubSpot deal, and uses Error Handlers so incomplete documents become actionable deal stages instead of silent failures.

Related: Form → Notion chassis/engine, Email → Airtable insurance, Drive → Sheets.

Architecture

Partner / mobile app
      |
      | POST JSON + file URLs
      v
Make Custom Webhook
      |
      +-- download RC front/back
      |
      v
Cryvis POST /v1/documents/indian-vehicle-rc
      |
      +-- success, complete fields --> HubSpot Deal: Onboarding
      |
      +-- success, missing chassis/engine --> Deal stage: Docs incomplete
      |
      +-- HTTP error --> Error Handler --> Deal stage: Extraction failed
                                         + ops alert

Webhook contract

{
  "onboarding_id": "veh_9f2a",
  "contact_email": "owner@example.com",
  "deal_name": "KA01AB1234 — Swift finance",
  "pipeline": "Vehicle onboarding",
  "files": {
    "rc_front": "https://storage.example/rc-front.jpg",
    "rc_back": "https://storage.example/rc-back.jpg"
  }
}

Rules:

• contact_email required for HubSpot association
• At least one of rc_front / rc_back required
• Prefer both for chassis_number / engine_number completeness

Step 1: Custom webhook + downloads

Webhooks → Custom webhook. Respond later with Webhook response after HubSpot writes.

HTTP → Get a file for each URL present → front_bin / back_bin.

Filter: if both URLs empty → immediate webhook 400 { "error": "rc_required" } (no Cryvis call).

Step 2: Cryvis extraction

POST https://api.cryvis.com/v1/documents/indian-vehicle-rc
Authorization: Bearer YOUR_API_KEY

multipart:
  front = front_bin   # if any
  back  = back_bin    # if any

Parse data:

registration_number
registration_date
owner_name
address
vehicle_class
manufacturer
model
chassis_number
engine_number
fuel_type
insurance_valid_upto
fitness_valid_upto
financier
source

API docs: /docs/api/extractIndianVehicleRc · /apis/indian-vehicle-rc.

Step 3: Completeness Router (business, not HTTP)

After a 2xx Cryvis response, branch:

Incomplete is still a successful API extract — the scanner returned JSON, but onboarding policy is not satisfied. Do not send incomplete deals down the “approved for underwriting” path.

        Cryvis 200
            |
     +------+------+
     |             |
 Complete      Incomplete
     |             |
 HubSpot       HubSpot
 stage A       stage B
 + note        + task "Upload other RC side"

Step 4: HubSpot contact + deal

1. HubSpot → Create/Update Contact by contact_email. Set name from owner_name when useful.
2. HubSpot → Create a Deal (or Update by onboarding_id stored in a custom deal property).

Deal properties:

Associate deal ↔ contact.

Optional: HubSpot note with address and financier for credit ops.

Step 5: Error Handler for failed extraction

Attach Make Error handler to the Cryvis HTTP module (this is HTTP failure, not incompleteness):

Cryvis HTTP
  |
  +-- Success --> Completeness Router --> HubSpot
  |
  +-- Error handler directive
        |
        +-- Resume: HubSpot Deal stage = Extraction failed
        |     properties: onboarding_id, contact email
        |     note: HTTP status + short error
        +-- Slack #vehicle-onboarding
        +-- Webhook response 502
              { "onboarding_id", "status": "extraction_failed" }

Common HTTP failures:

Incomplete documents must not go through this Error handler — they are success-path Router cases. Mixing them confuses ops SLAs (API down vs applicant photo quality).

Step 6: Webhook response shapes

Partners can safely retry incomplete by POSTing the missing side with the same onboarding_id; your HubSpot Update path should merge properties.

Step 7: Idempotency

Store onboarding_id → HubSpot deal_id in Make Data store:

IF datastores.get(onboarding_id)
  update existing deal
ELSE
  create deal; save mapping

Prevents duplicate deals when partners retry webhooks.

Step 8: Insurance stage hook (optional)

If insurance_valid_upto < today, set deal stage Insurance expired on RC even when chassis/engine are present — finance may still block. This is HubSpot policy layered on Cryvis dates.

Test matrix

1. Front+back happy path → deal RC extracted, webhook 200 with chassis/engine.
2. Front only, chassis null → deal Docs incomplete, webhook 200, task created.
3. Invalid token → Error handler → Extraction failed, webhook 502.
4. Replay same onboarding_id → one deal updated.
5. Empty files object → 400 before Cryvis.

HubSpot pipeline sketch

Vehicle onboarding pipeline
  1. Webhook received
  2. RC extracted          <- complete route
  3. Docs incomplete       <- completeness Router
  4. Extraction failed     <- Error handler
  5. Underwriting
  6. Closed won / lost

Only stages 2+ should enter underwriting automation. Gate HubSpot workflows on deal stage equals RC extracted AND chassis/engine properties known.

Partner SLA

Document for integrators:

Why Error Handler ≠ Incomplete

Ops dashboards that lump both as “RC errors” hide whether you have an API outage or a photo-quality problem.

Credits and cost control

Each image is 1 credit. Reject payloads whose URLs are not image/PDF before download when you can sniff Content-Type. Cap downloads at two files per onboarding_id.

Related reading

• Extract Indian Vehicle RC
• Automate vehicle email → Airtable
• Extract registration to Notion
• KYC Make.com guides: /blog/make-com

CTA

Onboard vehicles with Cryvis RC extraction: /apis/indian-vehicle-rc. Docs: /docs/api/extractIndianVehicleRc. From Make, webhook → multipart front/back → https://api.cryvis.com/v1/documents/indian-vehicle-rc with Bearer auth → HubSpot deals, with Error Handlers reserved for HTTP failures and a Completeness Router for missing chassis/engine.