Drive Indraft from n8n or Make, without writing code

The situation

You already run n8n or Make. You want a deal moving to trigger something, and you want things happening elsewhere to land in the CRM. In most products this is a page of code. Here it is two connections you configure once.

What must be true when you are done

• Indraft calls your automation when a specific thing happens.
• You can prove a call really came from Indraft rather than from anyone else.
• Your automation can write to Indraft with a credential scoped to only that.
• When a delivery fails you can see it failed, and why, without asking us.

Direction one: Indraft tells your automation

Create a webhook node in your tool and copy its address. Then register it, naming the events you want. Subscribe to what you actually need rather than everything: a workflow woken by every change in the workspace will spend most of its life deciding to do nothing, and you pay for that in your automation tool rather than here.

The secret is shown once, at registration, and never again. Put it in your automation tool's credential store at that moment. If you lose it, the fix is to roll it rather than to recover it.

Three refusals you will meet, and should

All three happen at registration, which is the right time to find out.

• An address that is not https is refused outright, because the delivery carries your customer records.
• An address on a private or internal range is refused: that address is on a private, loopback, or cloud-metadata range. If you are pointing at something inside your own network, the delivery has to reach a public address that you then forward, which your automation tool almost certainly already provides.
• An event name that does not exist is refused against the published list rather than accepted. This one matters more than it looks: a typo in an event name is otherwise indistinguishable from a quiet week, and you would find out when somebody asks why the workflow never ran.

Check the signature, or you have built an open door

Every delivery is signed with the secret from registration. Your workflow must verify it before acting, and this is not optional hardening: the address of your webhook node is the only thing anybody needs in order to post whatever they like into your automation.

In n8n and Make this is a single step before your logic, comparing the signature on the request against one computed from the body and your stored secret, and stopping the workflow when they do not match. Test it by sending a request with a wrong signature and confirming the workflow refuses. A verification step that has never rejected anything has not been shown to work.

When a delivery fails

It will, because your tool will have an outage or a workflow will be mid-edit. Failed deliveries are recorded and retried rather than dropped, and you can read exactly what happened:

That is a real failure from a real run: the endpoint answered 405 because it was not accepting posts. The point is what the record contains. The status your endpoint returned, how many attempts have been made, and when the next one is due. Debugging a webhook you cannot see the delivery log for is guesswork, and this is the difference between a five minute fix and an afternoon.

Direction two: your automation writes to Indraft

An HTTP request node, with a token created for this workflow and nothing else. Scope it to what the job needs: a workflow that creates contacts needs to write contacts, and does not need to reconfigure your pipeline or read your billing.

Two things to set on every write, and they are what separates an automation that stays clean from one that quietly corrupts a workspace over six months.

• Say where the value came from. Mark it as imported and label the source. Then when somebody asks in March why a contact's title is wrong, the answer is on the record rather than being a guess about which of four systems wrote it.
• Send a stable key derived from the source record. Not a random one per run. That is what makes the whole workflow safe to retry: the same source row processed twice produces one record, and your tool's automatic retry stops being something you have to think about.

What not to put here

Anything requiring judgment. Reading a call and deciding what it meant, choosing which of two companies a lead belongs to, writing a summary: those belong to an agent, and wiring them as automations produces confident nonsense on a schedule.

The line is worth holding deliberately, and it has its own recipe because getting it wrong in either direction is expensive. Automations that guess are the worse half.

Verify it

• Trigger the event for real. Move a deal and watch the workflow run. Do not trust a test payload from your automation tool: it will not carry a real signature and will not prove the connection.
• Send a bad signature. The workflow must refuse.
• Run the inbound workflow twice on the same source row. One record, not two.
• Break it on purpose. Disable your webhook node, trigger the event, and read the delivery log. Knowing where that log is before you need it is most of the value.

Run it again

Once per connection. When one breaks, the delivery log is the first place to look and usually the last. Posting to a channel is the smallest useful version of direction one, and keeping an outside copy in step is the version that does not need webhooks at all.