# Best practices

### [Subscribe to the minimum number of events](#subscribe-to-the-minimum-number-of-events) <a href="#subscribe-to-the-minimum-number-of-events" id="subscribe-to-the-minimum-number-of-events"></a>

You should only subscribe to the webhook events that you need. This will reduce the amount of work your server needs to do. For more information, see "[Creating webhooks.](/reference/creating-webhooks.md)"

### [Use a webhook secret](#use-a-webhook-secret) <a href="#use-a-webhook-secret" id="use-a-webhook-secret"></a>

You should set a webhook secret for your webhook and verify that the signature of each webhook delivery matches the secret. This helps to ensure that the webhook delivery is from Shopwaive. For more information, see "[Validating webhook deliveries](/reference/validating-webhook-deliveries.md)."

The webhook secret should be a random string of text with high entropy. You should securely store your webhook secret in a way that your server can access.

### [Use HTTPS and SSL verification](#use-https-and-ssl-verification) <a href="#use-https-and-ssl-verification" id="use-https-and-ssl-verification"></a>

You should ensure that your server uses an HTTPS connection. By default, Shopwaive will verify SSL certificates when delivering webhooks. Shopwaive recommends that you leave SSL verification enabled.

### [Allow Shopwaive's IP addresses](#allow-githubs-ip-addresses) <a href="#allow-githubs-ip-addresses" id="allow-githubs-ip-addresses"></a>

You can set up an IP allow list for your server, and add the IP addresses that Shopwaive uses for webhook deliveries. This can block spoofed requests to your server.

### [Respond within 10 seconds](#respond-within-10-seconds) <a href="#respond-within-10-seconds" id="respond-within-10-seconds"></a>

Your server should respond with a 2XX response within 10 seconds of receiving a webhook delivery. If your server takes longer than that to respond, then Shopwaive terminates the connection and considers the delivery a failure.

In order to respond in a timely manner, you may want to set up a queue to process webhook payloads asynchronously. Your server can respond when it receives the webhook, and then process the payload in the background without blocking future webhook deliveries. For example, you can use services like [Hookdeck](https://hookdeck.com/) or libraries like [Resque](https://github.com/resque/resque/) (Ruby), [RQ](http://python-rq.org/) (Python), or [RabbitMQ](http://www.rabbitmq.com/) (Java).

### [Check the event type and action before processing the event](#check-the-event-type-and-action-before-processing-the-event) <a href="#check-the-event-type-and-action-before-processing-the-event" id="check-the-event-type-and-action-before-processing-the-event"></a>

There are multiple webhook event types, and many events can have multiple action types. Shopwaive continues to add new event types and new actions to existing event types. Your application should check the event type and action of a webhook payload before processing the payload. To determine the event type, you can use the `X-Shopwaive-Event` request header. To determine the action type, you can use the top-level `action` key in the event payload.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://webhooks.shopwaive.com/reference/best-practices.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.