Endpoints To Schedule
Mailbase uses authenticated internal endpoints for background email work. Run them from your host cron, Vercel Cron, GitHub Actions, a worker scheduler, or any scheduler that can send an HTTP bearer token.
Both endpoints accept GET or POST for scheduler compatibility. POST is preferred when your platform supports it.
| Endpoint | Purpose | Recommended frequency |
|---|---|---|
| /api/internal/send-jobs | Enqueue due scheduled campaigns and process durable send-job batches. | Every minute |
| /api/internal/workflows | Fire due date/time workflow triggers and process queued workflow steps. | Every minute |
Cron Secret
Set CRON_SECRET in production and send it as a bearer token. INTERNAL_CRON_SECRET is accepted as a legacy alias. In local development without either secret, the endpoints allow calls so you can test the worker loop.
curl -X POST https://mailbase.example.com/api/internal/send-jobs \ -H "Authorization: Bearer $CRON_SECRET"
Deployment Pattern
- Create one schedule for /api/internal/send-jobs every minute.
- Create one schedule for /api/internal/workflows every minute if you use Journeys or date/time automation triggers.
- Set DATABASE_URL, AUTH_SECRET, CRON_SECRET, and your workspace sending credentials before enabling production cron.
- Keep the schedule frequent. Job rows control next_run_at, batch size, retries, and per-workspace concurrency, so duplicate scheduler ticks are safe.
Operational Checks
- The send worker returns scheduled campaign counts, processed recipient counts, and per-batch results.
- Runnable send-job states are queued, running, and retrying. Terminal states are sent, failed, and cancelled.
- Failed recipient details are stored on send_job_items.error and shown in the campaign failed-recipient view.
- The /api/health endpoint includes safe component checks for cron-sensitive dependencies.