Scan with Google Authenticator, 1Password, or any TOTP app — or enter the secret manually.
Using a client API key for a specific program? Connect with a key instead.
Forgot your password or lost your authenticator? Reset with the admin API key →
| ID | Job | Schedule | Next fire | Last fire | Health | Actions |
|---|
| ID | Name | Jobs | Status | Created | Actions |
|---|
Rotating kills the old key instantly and shows the replacement once. The admin key (from /etc/pulse.env) is managed on the server, not here.
Enter the site you want Pulse to trigger. Type only changes what we build: WordPress appends the standard /wp-json/pulse/v1/trigger path for the receiver plugin in step 3; Custom leaves your URL exactly as typed, for your own API route (church import checker, compliance endpoint, anything not WordPress).
Click through to + New job — the callback URL from step 1 comes with you. Choose Interval (every N seconds) or Schedule (specific times) and save. Creating it shows the HMAC secret once. Copy it now — step 3 uses it immediately, so there's no need to go find it again afterward.
WordPress sites: download the mu-plugin below, upload it to that site's wp-content/mu-plugins/ folder (cPanel File Manager or FTP — this is on the target site's own server, not Pulse's), then add one line to that site's wp-config.php using the secret from step 2:
One trip to wp-config.php, one line, done — no need to come back and edit it again.
Custom endpoints (church media check, compliance SaaS, anything not WordPress): use the signature reference below instead — it's a spec you can hand directly to a developer, an AI coding assistant, or a low-code builder like Base44 to implement as your receiving route.
Skip this if you used the WordPress plugin above — it already does this. If you're building your own receiver: every firing is a POST with a JSON body and two headers. This whole card is meant to be copy-pasted as-is into a build prompt or handed to whoever's implementing the endpoint.
| X-Pulse-Timestamp | Unix seconds when Pulse sent the request |
| X-Pulse-Signature | HMAC-SHA256 hex of "{timestamp}.{body}" using the job's secret from step 2 |
Reject anything where the timestamp is more than 5 minutes old (replay protection), and use a constant-time comparison for the signature — don't use === or == on the hex strings.
Node.js
PHP
Paste the callback URL and the job's secret — this computes a genuinely valid signature in your browser (nothing is sent anywhere except the curl command you choose to run) and gives you a ready-to-paste test.
A 200 response means the signature verified and the receiver ran. Run it, then check the job's Run History in the Jobs tab to confirm Pulse's real scheduled firings look the same.
Pulse's interval is a reliability guarantee for the tick, not a claim about when real work happens. It's fine — normal, even — to ping more often than anything actually needs to happen. Two patterns:
The tick is the schedule. Simple case: "check for new media every 5 minutes" — Pulse fires every 5 minutes, the receiver just does the check every time. No extra logic needed.
The tick is just a heartbeat; the site decides what's due. Compliance notices at exact times, or "only really check every 5 hours" even though Pulse pings every 5 minutes — the receiver looks at its own schedule/database on every tick and no-ops unless something is actually due. This is exactly how WordPress's own wp_cron() already behaves (the default receiver calls it directly), and the same pattern applies to any custom endpoint: Pulse guarantees delivery, your app owns the decision.
| Minimum interval | 60 seconds |
| Scheduler tick | every 30 seconds |
| Callback timeout | 30 seconds |
| Retries on failure | 30s, 2m, 10m after |
| Signature replay window | 5 minutes |
| Successful run retention | 90 days (RUN_RETENTION_DAYS) |
| Failed run retention | 365 days (FAILURE_RETENTION_DAYS) |
—