Webhooks

Use webhooks when you want Pickaxe to send outbound POST requests to your own automation stack whenever important portal or workspace events happen.

Big Picture

Webhooks are configured at the workspace level in Settings -> Webhooks.

Each webhook entry has:

• a destination URL
• one selected event type
• a built-in Test button so you can validate the destination before relying on live traffic

This is useful for tools like Zapier, Make, n8n, or your own backend when you want to:

• create CRM records when someone signs up
• notify your own system when a payment happens
• sync workspace membership changes
• kick off follow-up workflows after a conversation goes inactive

Plan Availability

Webhooks are marked as a Pro feature in the workspace settings UI.

Payload Shape

Pickaxe sends a POST request to your webhook URL.

The current product UI describes the shared payload as including:

• studioId
• studioName
• userEmail
• giftedProducts

The event type is also included in the webhook payload so your destination can branch on it.

Example Payload

{
  "studioId": "STUDIO73CVEX31DUTEC3J",
  "studioName": "Acme Portal",
  "userEmail": "user@example.com",
  "giftedProducts": ["starter-plan"],
  "event": "membership"
}

Event Types

Pickaxe currently exposes these webhook event types in the workspace settings UI:

Portal Sign Up

Fires when someone signs up to your portal.

• Event ID: signup

Portal Payment

Fires when someone makes a payment within your portal.

• Event ID: payment

Membership

Fires when someone becomes a member of your workspace.

• Event ID: membership

Conversation Ended

Fires when a Pickaxe conversation ends after more than 30 minutes of inactivity.

• Event ID: conversation

Testing

Each webhook row includes a Test button. Use it to confirm that your endpoint is reachable before you depend on live events.

Recommended Pattern

Most teams point these webhooks at an automation layer first, then fan out from there:

1. Send the webhook into Zapier, Make, n8n, or your own API.
2. Inspect the event field.
3. Route the payload into event-specific logic.
4. Store or forward the studioId, studioName, userEmail, and giftedProducts fields as needed.