42min

    How to connect 42min to n8n

    There's no 42min node in n8n, and you don't need one. 42min posts every booking event to a URL as a signed HTTPS delivery, and its REST API answers ordinary bearer-token requests. n8n's built-in Webhook and HTTP Request nodes are the whole integration.

    Open Admin Center → API →

    Two-way synchronization

    Two-way flow: 42min sends webhooks into n8n, and n8n sends API requests back to 42min

    Events out. A webhook is a URL on your side that 42min calls the moment a booking is created, rescheduled, canceled, marked a no-show, or edited. Point one at an n8n Webhook node and every one of those moments becomes a workflow run.

    Actions in. The Public REST API reads and writes the same data you see in the dashboard: free slots, bookings, event types. The same workflow can answer back, whether that's creating a booking, moving one, or stamping a CRM id onto it.

    Bookings into n8n in 3 steps

    01

    Start an n8n workflow with a Webhook node

    Add a Webhook node, set its method to POST, and copy the Production URL. The Test URL only listens while you're clicking “Listen for test event”. On n8n Cloud the URL is already public HTTPS, which is what 42min requires.

    02

    Register the URL in 42min

    In Admin Center → API, open the Webhooks tab and click Add webhook. Paste the n8n URL, pick the events this flow cares about, and save. 42min shows the webhook's signing secret exactly once; store it now, you'll need it to verify deliveries.

    03

    Send a test, then go live

    Use Send test on the webhook's row to fire a synthetic booking.created at n8n, and View logs to watch the delivery land. When the run looks right, activate the n8n workflow so the Production URL is listening around the clock.

    Step 02 in the product: paste the n8n Production URL, tick the events this flow cares about, and Create. The signing secret appears right after.

    Prove it's really 42min

    An unverified webhook endpoint accepts anything that finds the URL. Every 42min delivery therefore carries X-42min-Webhook-Signature: t=<unix seconds>,v1=<signature>, where v1 is an HMAC-SHA256 of timestamp.body computed with your webhook's signing secret. This is where n8n outclasses point-and-click automation tools: a Code node can actually check it.

    Enable Raw Body on the Webhook node (the HMAC must be computed over the bytes exactly as received), then make this the first node after it: 

    // Code node · “Run Once for Each Item”.
// Upstream Webhook node: method POST, “Raw Body” enabled.
const crypto = require('crypto');

// The 42min_wh_… signing secret, shown once when the webhook was added.
// $vars needs n8n Variables; on self-hosted n8n, $env works too.
const secret = $vars.FORTYTWOMIN_WEBHOOK_SECRET;

// Header: X-42min-Webhook-Signature: t=<unix seconds>,v1=<hex hmac>
const header = $json.headers['x-42min-webhook-signature'] ?? '';
const { t, v1 } = Object.fromEntries(header.split(',').map((p) => p.split('=')));

// HMAC over the raw bytes exactly as received. Never re-stringify the
// parsed body; re-serializing can reorder keys and break the comparison.
const raw = Buffer.from($input.item.binary.data.data, 'base64');
const expected = crypto
  .createHmac('sha256', secret)
  .update(t + '.' + raw.toString('utf8'))
  .digest('hex');

const stale = Math.abs(Date.now() / 1000 - Number(t)) > 300; // ~5 minutes
const genuine =
  !!v1 && v1.length === expected.length &&
  crypto.timingSafeEqual(Buffer.from(v1, 'hex'), Buffer.from(expected, 'hex'));

if (stale || !genuine) throw new Error('Not a genuine 42min delivery');

return { json: JSON.parse(raw.toString('utf8')) };

    Everything downstream now handles verified, parsed JSON. On self-hosted n8n, allow the built-in module with NODE_FUNCTION_ALLOW_BUILTIN=crypto. If the secret ever leaks, Rotate secret on the webhook's row issues a new one and kills the old one immediately.

    Call 42min back from the same flow

    Mint a personal access token on the API keys tab. It's shown once, and it should carry only the scopes the flow needs. In n8n, store it as a Header Auth credential sending Authorization: Bearer 42min_pat_…, and every HTTP Request node in the workflow can use it to read free slots, create bookings, cancel or reschedule them, and write CRM ids back into a booking's metadata.

    Every write takes an Idempotency-Key header, which turns n8n retries from a double-booking risk into a no-op, and n8n has the perfect value for it built in: 

    POST https://api.42min.us/v1/bookings
Authorization:   Bearer 42min_pat_…            ← Header Auth credential
Content-Type:    application/json
Idempotency-Key: {{ $execution.id }}-{{ $itemIndex }}

{
  "event_type_id": "01HXXX…",
  "start": "2026-09-03T10:00:00Z",
  "timezone": "Europe/Berlin",
  "attendee": { "email": "bob@example.com", "name": "Bob Builder" },
  "metadata": { "crm_id": "C-7" }
}

    The {{ $itemIndex }} suffix matters when one run creates several bookings: each item needs its own key. Full request shapes in /v1/bookings.

    Case study

    The sales-operations team at Snov.io runs its booking-to-CRM pipeline on exactly the pattern above (one 42min webhook into n8n, Pipedrive as the CRM) and shared the flows behind it. Every meeting booked through 42min becomes a fully-formed CRM record before the rep even opens their laptop.

    300
    Bookings / 30 days
    94
    Deals created automatically
    0
    Manual data entry

    One webhook, seven decisions

    42min posts the booking. The flow checks whether the person already exists in the CRM, creates the contact and company when they don't, opens the deal, assigns the right sales rep, and logs the meeting as an activity on the record. The rep is notified the moment the record is ready: no handoff, no copy-paste.

    Booking → CRM: every path ends with a rep owning a meeting that's already on the record.

    The real pipeline handles every edge case

    A booking rarely arrives on a blank slate. The person may already have an open deal, a lost one worth reopening, or a colleague already in the CRM. Job titles get normalised, ownership is resolved, the lead score is recalculated, and duplicate companies raise a warning instead of a mess. Same trigger, every path ending in an owned meeting.

    The simple version, grown up: the branches are edge cases met in production, not speculation.

    A watchdog that notices silence

    An integration that stops delivering looks exactly like a quiet week. That's the failure mode nobody sees. This team's third flow runs on a schedule, compares bookings against deals created, and raises an alert the moment the two stop matching. It was built after a webhook paused itself and six days of bookings went unnoticed. The pause is documented 42min behavior: after five consecutive failed deliveries a webhook auto-pauses until you re-enable it. The watchdog turns that silent state into a loud one, and GET /v1/bookings?updated_since=… backfills whatever the pause swallowed.

    Three nodes on a schedule: if bookings and deals stop matching, someone hears about it the same day, not six days later.

    42min + n8n FAQ

    No, and none is needed. n8n's built-in Webhook node receives 42min's booking events, and its HTTP Request node calls the 42min REST API. There's nothing to install on either side, and the same two primitives work in any n8n version, Cloud or self-hosted.

    Every booking, everywhere it matters

    Signed webhooks and a full REST API on every plan, so the scheduler you give people is also the trigger your stack runs on.

    Create 42min account →

    No credit card · Free plan · Every feature unlocked