How do I decide between custom Laravel middleware and an off-the-shelf integration platform?

Choose custom Laravel code when the integration logic is tied closely to your own business rules and you’re only connecting to one or two systems. Choose an off-the-shelf integration platform, such as Zapier, Make, or Workato, when you’re connecting several third-party tools, the workflows change often, or people outside engineering need to maintain them. The clearest signal isn’t which one sounds more technical, it’s who owns the logic and how often it needs to change.

What “custom Laravel middleware” actually means

Middleware in Laravel has a specific meaning: a class in the HTTP request and response pipeline, used for things like auth checks, rate limiting, or transforming a request before it reaches a controller. Since Laravel 11, that’s configured in bootstrap/app.php rather than the app/Http/Kernel.php file older versions used. If your need is genuinely that, real middleware is the right tool. Most people asking this question mean something broader though: custom integration code in general, usually a service class, a queued job, or an API client built on Laravel’s HTTP client, not literal middleware. What you’re really comparing is code you own and deploy against a hosted tool you configure.

The factors that actually decide it

• Integration count. One or two systems favor custom code. Four or more, especially ones with existing connectors, favor a platform.
• Logic complexity. Anything that needs to check your own database, apply pricing rules, or branch on internal application state belongs in your codebase, where it can be tested and reviewed.
• Processing model. Middleware runs synchronously inside the request lifecycle, so it’s a poor fit for long-running work like heavy transformations or multi-step retries. Laravel’s queue system handles that asynchronously in-house; a platform handles it natively outside your app entirely.
• Who maintains it. If someone outside engineering needs to adjust the workflow without a deploy, use a platform. If only developers will touch it, keeping it in Laravel avoids a second system to manage.
• Data sensitivity. Routing customer or payment data through a third-party platform adds a vendor to your compliance surface.

What to avoid

Do not let a middleware class grow into a general-purpose integration layer just because Laravel handles the first request. Once it’s coordinating several external APIs and business rules, it becomes hard to test and harder to hand off. And do not reach for a platform to enforce a rule that’s really just an application concern, that’s adding a system to operate for something a five-line middleware class already handles.

Many teams end up mixing both: a platform for the simple, frequently changing connections, and custom Laravel code for the integrations that carry real business logic or sensitive data.

Neither approach is better engineering on its own. Count your integrations, be honest about how much of the logic is genuinely yours, and decide who’s maintaining this in a year.