Schedule standby delivery

Schedule Standby Delivery is a tiny Actor with one job: POST a JSON payload to a URL you configure, authenticated with a shared secret. Point an Apify schedule at it and it becomes a cron trigger for any HTTP endpoint — a standby Actor, an internal API, a webhook receiver.

What does Schedule Standby Delivery do?

It takes three things — a target URL, a JSON payload, and a secret — and sends the payload to the URL as an HTTP POST with Content-Type: application/json. The secret goes out in the Authorization: Bearer <secret> header so the receiving endpoint can reject anything that is not from you. The body also carries a _apifyRun object describing the run that sent it, including the ID of the schedule that triggered it. The status, headers, and body of the response are stored in the run's key-value store and dataset, so every scheduled delivery leaves an auditable record.

Running it on the Apify platform gives you scheduling, run history, retries, alerting, and API access without hosting a cron job yourself.

Why use Schedule Standby Delivery?

• Wake up a standby Actor on a schedule. Apify schedules start Actor runs; they do not send HTTP requests. This Actor bridges the gap.
• Trigger any webhook on a cron. Nightly reindex, hourly cache warm-up, weekly report generation — anything behind an HTTP endpoint.
• Keep the secret out of the schedule config. The secret is a secret input field: it is encrypted at rest and censored in the Console.
• A schedule that never looks broken. A rejected or unreachable endpoint is recorded as a failed delivery, not as a failed run, so your run history stays readable and alerting stays under your control.

How to use Schedule Standby Delivery

1. Open the Actor's Input tab.
2. Fill in the Target URL you want to call.
3. Paste the JSON payload the endpoint expects (leave it as {} if the call itself is the signal).
4. Enter the Secret your endpoint checks for.
5. Click Start to test it once, then create a Schedule with the same input to run it periodically.

Input

Field	Type	Required	Default	Description
url	string	yes	—	Absolute http(s) URL the payload is POSTed to.
payload	object	no	{}	JSON object sent as the request body.
secret	string (secret)	yes	—	Sent verbatim as Authorization: Bearer <secret>.
maxRetries	integer	no	3	Extra attempts after the first one.

Each attempt times out after 120 seconds.

{
    "url": "https://my-actor.apify.actor/deliver",
    "payload": { "repositoryUrl": "https://github.com/owner/repo", "mode": "nightly" },
    "secret": "<your secret>",
    "maxRetries": 3
}

What the receiver gets

The request body is the payload you configured, plus one reserved key, _apifyRun, holding what the platform knows about the run that sent it. The input above is delivered as:

{
    "repositoryUrl": "https://github.com/owner/repo",
    "mode": "nightly",
    "_apifyRun": {
        "origin": "SCHEDULER",
        "runId": "aBc123XyZ",
        "scheduleId": "sChEd123",
        "scheduledAt": "2026-08-19T02:00:00.000Z"
    }
}

Field	Description
origin	How the run started: SCHEDULER for a scheduled run, WEB for a manual one, API, CLI, …
runId	ID of the run that sent the request. Useful for correlating the receiver's logs with the run log.
scheduleId	ID of the schedule that triggered the run. Absent when no schedule triggered it.
scheduledAt	ISO timestamp of when the schedule fired. Absent along with scheduleId.

Fields the platform did not report are left out rather than sent as null, so a receiver can treat "has a scheduleId" as "this was a scheduled delivery". Reading them costs one API call before the delivery; if that call fails, the payload is still delivered and _apifyRun carries only what was already known.

_apifyRun is reserved: a payload key of the same name is replaced by the real run metadata. Every other payload key is passed through untouched at the top level, so a receiver that ignores _apifyRun needs no changes.

Output

The result is written to the OUTPUT record of the default key-value store and pushed to the default dataset. You can download the dataset in various formats such as JSON, HTML, CSV, or Excel.

{
    "url": "https://my-actor.apify.actor/deliver",
    "ok": true,
    "requestBodyBytes": 74,
    "runMeta": {
        "origin": "SCHEDULER",
        "runId": "aBc123XyZ",
        "scheduleId": "sChEd123",
        "scheduledAt": "2026-08-19T02:00:00.000Z"
    },
    "attempts": [{ "attempt": 1, "status": 200, "durationMillis": 412 }],
    "response": {
        "status": 200,
        "statusText": "OK",
        "headers": { "content-type": "application/json" },
        "body": "{\"accepted\":true}"
    },
    "finishedAt": "2026-08-10T02:00:00.412Z"
}

Field	Description
url	The URL that was called.
ok	true when the endpoint answered with a 2xx status.
requestBodyBytes	Size of the JSON body that was sent.
runMeta	The _apifyRun object that went out with the payload.
attempts	One entry per attempt, with its status or error and duration.
response	Status, status text, headers, and body (truncated at 10,000 characters). Absent when no response was ever received.
error	Message of the final failure. Absent on success.
finishedAt	ISO timestamp of when the delivery finished.

Retries and failures

Network errors, timeouts, and the statuses 408, 425, 429, and 5xx are retried up to maxRetries times with exponential backoff (1s, 2s, 4s, … capped at 30s). Statuses the receiver decided on — 400, 401, 404, and friends — are final and are not retried.

The run itself succeeds even when the delivery does not. Check ok in the output to tell the two apart; the run only fails when the input is invalid (missing URL, non-http(s) URL, missing secret). If you want alerting on failed deliveries, monitor the dataset field rather than the run status.

Cost estimation

One run is a single HTTP request and finishes in seconds, so it consumes a negligible fraction of a compute unit — well within the Apify free tier even at hourly frequency. The dominant cost is the endpoint you are calling, not this Actor.

Tips

• Give each schedule its own input so one endpoint's payload change never affects another.
• Set maxRetries to 0 for non-idempotent endpoints; a retried POST is a second delivery from the receiver's point of view.
• Answer quickly and do the work asynchronously if the endpoint is slow — each attempt is abandoned after 120 seconds.
• Verify the bearer token on the receiving side with a constant-time comparison, and reject requests that do not carry it.

FAQ and support

Does it support HTTP methods other than POST? No — the Actor always POSTs a JSON body. That keeps it predictable as a scheduled trigger.

How does the receiver tell which schedule triggered a delivery? Read _apifyRun.scheduleId from the body. It is present only when a schedule started the run, so a manual test run is distinguishable from a scheduled one.

Is the secret HMAC-signed? No. It is transmitted as a bearer token over TLS, so use an https:// URL and treat the secret like any other credential.

Where do I report problems? Use the Issues tab of the Actor on Apify Console.