HTTP request recipes

Connect the tools
you already use.

CronEngine already schedules outbound HTTP requests. These guides show how to use that existing functionality with endpoints supplied by your application or the service you use.

One request, on schedule

The same pattern works almost anywhere

1

Choose a public endpoint

Use a route, API action, or generated hook URL.

2

Add the request details

Select the method, authentication, headers, and optional body.

3

Set the schedule

Preview upcoming runs, save the job, and inspect the first result.

These are setup guides, not native account connections. CronEngine does not sign in to Laravel, WordPress, GitHub, or Vercel. You create a normal cron job using an endpoint and, where needed, a dedicated credential. No CronEngine public API is required for these recipes.

Keep integration credentials separate. CronEngine stores job URLs, authentication secrets, and custom header values as entered so it can make requests. Use a unique, limited token for each integration and revoke it if the job or URL is exposed.

Laravel Scheduler

Bridge Laravel’s scheduler through a protected route.

Laravel normally runs schedule:run from a server cron every minute. CronEngine cannot execute Artisan directly, so your application needs a small HTTPS route that checks a unique token before calling it.

CronEngine job settings

URL
https://your-app.com/cronengine/schedule
Method
POST
Authentication
Bearer token
Schedule
* * * * *
Overlap protection
On
Laravel evaluates due tasks when schedule:run is called. A complete Laravel Scheduler bridge therefore needs every-minute execution, which currently fits Business and Enterprise plans. For lower plans, expose and schedule one specific queued task instead. Sub-minute Laravel schedules are not a good fit for an HTTP bridge.
Laravel scheduler documentation ↗
Laravel route
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Artisan;
use Illuminate\Support\Facades\Route;

Route::post('/cronengine/schedule', function (Request $request) {
    $expected = (string) config('services.cronengine.secret');
    $provided = (string) $request->bearerToken();

    abort_if(
        $expected === '' || ! hash_equals($expected, $provided),
        403
    );

    $exitCode = Artisan::call('schedule:run');

    return response()->json(
        ['ok' => $exitCode === 0],
        $exitCode === 0 ? 200 : 500
    );
});
Secret configuration
// config/services.php
'cronengine' => [
    'secret' => env('CRONENGINE_SECRET'),
],

// .env
CRONENGINE_SECRET=generate-a-long-unique-token
WordPress

Run WP-Cron without waiting for visitors.

Disable WordPress’s page-load trigger only after the external CronEngine job is ready. CronEngine then requests wp-cron.php on a predictable interval.

Open the complete WordPress guide

Quick recipe

1. wp-config.php

define( 'DISABLE_WP_CRON', true );

Place this before the “stop editing” comment, after confirming the external job works.

2. CronEngine job

URL
https://your-site.com/wp-cron.php?doing_wp_cron
Method
GET
Schedule
Every 15 minutes on Free or every 5 minutes on Starter

Choose an interval that matches how much delay your scheduled posts and plugin tasks can tolerate. If a firewall blocks wp-cron.php, allow CronEngine’s documented outbound IP.

WordPress external scheduler documentation ↗
GitHub Actions

Dispatch a workflow from CronEngine.

Add the workflow_dispatch event to the workflow, then call GitHub’s workflow-dispatch endpoint with a token that has Actions write access to that repository.

CronEngine job settings

URL
https://api.github.com/repos/OWNER/REPO/actions/workflows/WORKFLOW_FILE/dispatches
Method
POST
Authentication
Bearer token
Content type
application/json
Success
Default 2xx rule
GitHub workflow API documentation ↗
.github/workflows/cronengine.yml
name: CronEngine task

on:
  workflow_dispatch:

jobs:
  scheduled-task:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/nightly-task.sh
Custom headers
Accept: application/vnd.github+json
X-GitHub-Api-Version: 2026-03-10
JSON body
{
  "ref": "main"
}

Replace WORKFLOW_FILE with the workflow file name, such as cronengine.yml. The ref must name a branch or tag that contains the workflow.

Vercel

Call a protected function or schedule a deployment.

For application work, expose a route that checks a bearer secret. For a scheduled rebuild, create a Vercel Deploy Hook and let CronEngine send a POST request to its generated URL.

Protected function

Set CRON_SECRET in Vercel, use the same value as CronEngine’s Bearer token, and call your production route with GET.

Deploy Hook

Create it under Project Settings → Git → Deploy Hooks. Use POST with no body. The unique hook URL can trigger deployments, so treat the URL itself as a secret.

app/api/cron/route.js
export function GET(request) {
  const authorization = request.headers.get('authorization');

  if (
    !process.env.CRON_SECRET ||
    authorization !== `Bearer ${process.env.CRON_SECRET}`
  ) {
    return new Response('Unauthorized', { status: 401 });
  }

  // Queue or perform your scheduled work here.
  return Response.json({ success: true });
}

Function job

https://your-app.vercel.app/api/cron

GET · Bearer token · no body

Deploy Hook job

https://api.vercel.com/v1/integrations/deploy/...

POST · no authentication field · no body

Any HTTP API

Use the same request options with your own endpoint.

CronEngine supports GET, POST, PUT, PATCH, DELETE, and HEAD. Add custom headers, a JSON or text body where supported, Basic or Bearer authentication, and success rules that match the endpoint.

  • Return a 2xx response when the request was accepted.
  • Queue long-running work and respond quickly when possible.
  • Use a unique secret and compare it before doing any work.
  • Keep overlap protection on unless concurrent calls are safe.

Example request

POST
URL
https://api.example.com/tasks/reindex
Authentication
Bearer token
Custom header
X-Job-Source: cronengine
Success rule
2xx status codes

JSON body

{
  "source": "cronengine",
  "task": "refresh-search-index"
}

Ready to connect one?

Turn an allowed public endpoint into a scheduled job.

Start with one of these recipes, test the request from the form, and use run history to confirm the integration behaves as expected.