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
Choose a public endpoint
Use a route, API action, or generated hook URL.
Add the request details
Select the method, authentication, headers, and optional body.
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.
Laravel
Call a protected scheduler route that you add to your app.
WordPress
Request WordPress’s existing WP-Cron endpoint.
GitHub Actions
Call GitHub’s workflow-dispatch API with your token.
Vercel
Request your function or a Vercel-generated deploy hook.
HTTP APIs
Schedule requests using the options CronEngine supports today.
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.
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
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.
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
);
});
// config/services.php
'cronengine' => [
'secret' => env('CRONENGINE_SECRET'),
],
// .env
CRONENGINE_SECRET=generate-a-long-unique-token
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.
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.
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
name: CronEngine task
on:
workflow_dispatch:
jobs:
scheduled-task:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: ./scripts/nightly-task.sh
Accept: application/vnd.github+json
X-GitHub-Api-Version: 2026-03-10
{
"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.
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.
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
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.