Download the PHP package spatie/laravel-github-webhooks without Composer

Handle GitHub webhooks in a Laravel application

GitHub can notify your application of events using webhooks. This package can help you handle those webhooks.

Out of the box, it will verify the GitHub signature of all incoming requests. All valid calls will be logged to the database. The package allows you to easily define jobs or events that should be dispatched when specific webhooks hit your app.

Here's an example of such a job.

Before using this package we highly recommend reading the entire documentation on webhooks over at GitHub.

Are you a visual learner?

In this stream on YouTube, I show how to use package, go over the source code, and explain how the package is tested.

Support us

We invest a lot of resources into creating best in class open source packages. You can support us by buying one of our paid products.

We highly appreciate you sending us a postcard from your hometown, mentioning which of our package(s) you are using. You'll find our address on our contact page. We publish all received postcards on our virtual postcard wall.

Installation

You can install the package via composer:

You must publish the config file with:

This is the contents of the config file that will be published at config/github-webhooks.php:

In the signing_secret key of the config file you should add a valid webhook secret. You can find the secret used at the webhook configuration settings on the GitHub dashboard.

Next, you must publish the migration with:

After the migration has been published, you can create the github_webhook_calls table by running the migrations:

Finally, take care of the routing: At the GitHub webhooks settings of a repo you must configure at what URL GitHub webhooks should be sent. In the routes file of your app you must pass that route to the Route::githubWebhooks route macro:

Make sure when configuring the webhook url that the webhooks are send as application/json and not as application/x-www-form-urlencoded.

Behind the scenes this macro will register a POST route to a controller provided by this package. We recommend to put it in the api.php routes file, so no session is created when a webhook comes in, and no CSRF token is needed.

Should you, for any reason, have to register the route in your web.php routes file, then you must add that route to the except array of the VerifyCsrfToken middleware:

Usage

GitHub will send out webhooks for several event types. You can find the full list of events types in the GitHub documentation.

GitHub will sign all requests hitting the webhook url of your app. This package will automatically verify if the signature is valid. If it is not, the request was probably not sent by GitHub.

Unless something goes terribly wrong, this package will always respond with a 200 to webhook requests. Sending a 200 will prevent GitHub from resending the same event over and over again. All webhook requests with a valid signature will be logged in the github_webhook_calls table. The table has a payload column where the entire payload of the incoming webhook is saved.

If the signature is not valid, the request will not be logged in the github_webhook_calls table but a Spatie\GitHubWebhooks\WebhookFailed exception will be thrown. If something goes wrong during the webhook request the thrown exception will be saved in the exception column. In that case the controller will send a 500 instead of 200.

There are two ways this package enables you to handle webhook requests: you can opt to queue a job or listen to the events the package will fire.

Handling webhook requests using jobs

If you want to do something when a specific event type comes in you can define a job that does the work. Here's an example of such a job:

We highly recommend that you make this job queueable, because this will minimize the response time of the webhook requests. This allows you to handle more GitHub webhook requests and avoid timeouts.

After having created your job you must register it at the jobs array in the github-webhooks.php config file. The key should be the name of the GitHub event type. Optionally, you can let it follow with a dot and the value that is in the action key of the payload of a event.

Working with a GitHubWebhookCall model

The Spatie\GitHubWebhooks\Models\GitHubWebhookCall model contains some handy methods:

• headers(): returns an instance of Symfony\Component\HttpFoundation\HeaderBag containing all headers used on the request
• eventActionName(): returns the event name and action name of a webhooks, for example issues.opened
• payload($key = null): returns the payload of the webhook as an array. Optionally, you can pass a key in the payload which value you needed. For deeply nested values you can use dot notation (example: $githubWebhookCall->payload('issue.user.login');).

Handling webhook requests using events

Instead of queueing jobs to perform some work when a webhook request comes in, you can opt to listen to the events this package will fire. Whenever a valid request hits your app, the package will fire a github-webhooks::<name-of-the-event> event.

The payload of the events will be the instance of GitHubWebhookCall that was created for the incoming request.

Let's take a look at how you can listen for such an event. In the EventServiceProvider you can register listeners.

Here's an example of such a listener:

We highly recommend that you make the event listener queueable, as this will minimize the response time of the webhook requests. This allows you to handle more GitHub webhook requests and avoid timeouts.

The above example is only one way to handle events in Laravel. To learn the other options, read the Laravel documentation on handling events.

Deleting processed webhooks

The Spatie\GitHubWebhooks\Models\GitHubWebhookCall is MassPrunable. To delete all processed webhooks every day you can schedule this command.

All models that are older than the specified amount of days in the prune_webhook_calls_after_days key of the github-webhooks config file will be deleted.

Advanced usage

Retry handling a webhook

All incoming webhook requests are written to the database. This is incredibly valuable when something goes wrong while handling a webhook call. You can easily retry processing the webhook call, after you've investigated and fixed the cause of failure, like this:

Performing custom logic

You can add some custom logic that should be executed before and/or after the scheduling of the queued job by using your own model. You can do this by specifying your own model in the model key of the github-webhooks config file. The class should extend Spatie\GitHubWebhooks\ProcessGitHubWebhookJob.

Here's an example:

Determine if a request should be processed

You may use your own logic to determine if a request should be processed or not. You can do this by specifying your own profile in the profile key of the github-webhooks config file. The class should implement Spatie\WebhookClient\WebhookProfile\WebhookProfile.

GitHub might occasionally send a webhook request more than once. In this example we will make sure to only process a request if it wasn't processed before.

Changelog

Please see CHANGELOG for more information about what has changed recently.

Testing

Contributing

Please see CONTRIBUTING for details.

Security

If you've found a bug regarding security please mail [email protected] instead of using the issue tracker.

Credits

• Freek Van der Herten
• All Contributors

License

The MIT License (MIT). Please see License File for more information.