Webhook

A webhook is a message that one piece of software sends to another as soon as something happens. A customer pays, a parcel ships, a subscriber signs up, and the first app immediately tells the second app about it. Nobody has to press a button, and the second app does not have to keep asking whether anything is new.

You meet webhooks even if you never write code. They are what makes a payment provider confirm an order in your store, what makes a shipping tool send a tracking number back, and what lets an automation service copy each new customer into a spreadsheet. If you sell online, choose tools or hire a developer to connect them, knowing what a webhook does helps you ask the right questions and spot the weak link when something breaks.

What is a webhook?

A webhook is an HTTP request that an app sends automatically to a web address you give it, each time a chosen event occurs. The address is called the endpoint or the callback URL. The request carries a small package of data, usually in JSON, describing the event: which order, what amount, which customer, at what time.

The simplest way to picture it is the difference between checking your mailbox and getting a text message. With a classic API call, your app goes to the other app and asks "anything new?" This is called polling. With a webhook, the other app comes to you the moment there is news. Developers sometimes call webhooks "reverse APIs" or "push notifications between servers" for that reason.

A webhook is not an API in itself. It is one pattern that APIs use. Most services that send webhooks also offer a regular API, and a solid integration uses both: the webhook says "order 4812 was refunded", and your app then calls the API to fetch the full, trusted details. A webhook is also not an email or a notification for a human. It is meant for a machine to read.

Related vocabulary you will see in tool settings:

• Event or topic: the kind of thing that triggers the message, such as order.paid or customer.created.
• Payload: the data sent with the message.
• Signature or secret: a code that proves the message really comes from the sender.
• Retry: a new attempt when the first delivery fails.
• Idempotency: the ability to receive the same message twice without doing the work twice.

Webhooks are a building block of event-driven architecture, where systems react to events instead of running on a timer.

Why it matters

Webhooks decide how fast and how reliably your tools agree with each other. When they work, your store, your payment provider, your email tool and your warehouse all share the same truth within seconds. When they fail silently, you get paid orders that never appear, emails that never go out and stock that is wrong.

Take a store with 800 orders a month and an average order of $45. Say an external fulfillment app learns about new orders through a webhook, and the endpoint breaks during a weekend because a developer changed a server setting. If nobody notices for 48 hours, around 53 orders sit unshipped. If a quarter of those customers write to support and 10% ask for a refund, you lose about $240 in refunds plus several hours of support, not counting the reviews. A simple alert on failed deliveries would have caught it in minutes.

Webhooks also change what integrations cost. Polling every minute means 43,200 requests a month per connection, most of them returning nothing. Many services limit or bill API calls, so a freelancer who builds an integration on polling can burn through a quota and slow everything down. A webhook sends one request per real event. For a creator with 150 sales a month, that is 150 messages instead of tens of thousands of empty checks.

How it works

The mechanism is the same whatever the tools involved:

• You register an endpoint. In the sending app, you (or your developer) paste a URL that belongs to the receiving app, and you pick which events to subscribe to.
• An event happens. A customer completes checkout, a refund is issued, a shipment gets a tracking number.
• The sender builds a payload. It packs the event type, an ID, a timestamp and the relevant data into a JSON message.
• The sender signs and sends it. It adds a signature computed with a shared secret, then makes an HTTP POST request to your endpoint over HTTPS.
• The receiver checks and answers fast. It verifies the signature, stores the message and replies with a success code (a 2xx status) within a few seconds. Heavy work happens afterwards, in the background.
• The sender retries on failure. If it gets an error or no answer, it tries again later, often with growing delays over hours or days. After too many failures, some services disable the endpoint.
• The receiver handles duplicates. Because retries exist, the same event can arrive twice. The receiver uses the event ID to make sure it only creates the shipment or sends the email once.

Order is not guaranteed either. An "order updated" message can arrive before "order created". Good receivers read the timestamp or fetch the current state through the API instead of trusting arrival order.

Benchmarks and examples

There is no single score for webhooks, but these reference points help you judge a tool or a freelancer's work:

• Delivery time. Most services deliver within 1 to 10 seconds of the event. More than a minute on a normal day suggests a problem on one side.
• Response time. Receivers should answer in under 5 to 10 seconds. Many senders give up after 10 to 30 seconds and count it as a failure.
• Retry window. Common policies retry for 24 hours to 3 days. If your endpoint is down longer, you must replay or reconcile events by hand.
• Failure rate. A healthy integration fails well under 1% of deliveries. Repeated failures above a few percent mean something needs fixing.

Typical situations:

• A creator selling a course uses a webhook from the payment provider to add each buyer to a private community tool.
• A small brand sends a webhook to a shipping tool on each paid order, and the shipping tool sends one back with the tracking number, which feeds order tracking emails.
• A founder building an MVP connects a form to an automation service that posts each new lead into a team chat.

Common mistakes

• Not verifying the signature. Anyone who guesses your endpoint URL could send fake "order paid" messages. Always check the signature before acting.
• Doing slow work before answering. Generating a PDF or calling three other services before replying causes timeouts, retries and duplicates.
• Ignoring duplicates. Without an idempotency check, a single retry can ship two parcels or send two invoices.
• No monitoring. Many teams learn a webhook broke from an angry customer. Failed deliveries should trigger an alert.
• Treating the webhook as the only source of truth. Messages get lost. A daily reconciliation through the API catches what slipped through.

Best practices

• Subscribe only to what you use. Fewer events mean less noise, less load and fewer things that can break.
• Verify, store, then process. Check the signature, save the raw event, reply with success, and process it in a background job.
• Use the event ID as a key. Record every processed ID so duplicates are skipped safely.
• Watch the delivery log. Most senders keep a log of attempts. Check it after any server change and set up alerts on failures.
• Plan a replay. Make sure you or your developer can re-send or re-fetch events after an outage.
• Keep secrets private. Store the signing secret like a password and rotate it if a contractor leaves.
• Ask for it in writing. When you hire a developer for an integration, list signature checks, retries, duplicate handling and monitoring in the acceptance criteria.

In Roctify

Roctify does not offer public webhooks today. For most sellers, that is less of a gap than it sounds, because the tasks people usually wire together with webhooks already happen inside one system. Your link-in-bio page and your storefront share one catalog, so stock, orders and customers update everywhere at once. Payments through Stripe and PayPal confirm orders directly in the store, and digital products and courses are delivered automatically after payment. Email marketing and forms live in the same account on the Creator plan and up, so a new buyer does not need to be pushed to a separate tool.

When you compare platforms, count how many external tools you would need to glue together with webhooks, and who would maintain that glue. If your business needs integrations beyond the built-in features, such as a custom ERP or warehouse system, those are discussed on the Enterprise plan.

FAQ

Is a webhook the same as an API?

No. An API is the full set of ways one app lets others talk to it, usually on request. A webhook is a specific pattern where the app sends data to you on its own when an event happens. Most integrations use both, with the webhook as the alarm and the API as the source of details.

Do I need a developer to use webhooks?

Not always. Automation services let you receive webhooks and trigger actions without code, which is enough for simple flows like "new lead goes to a spreadsheet". For anything touching money, stock or shipping, a developer who handles signatures, retries and duplicates is worth the cost.

What happens if my endpoint is down?

The sender usually retries for a period that ranges from a few hours to a few days. If your endpoint comes back in time, the events arrive late but arrive. If not, they are lost and you need to replay them or compare records through the API to fill the gap.