You have an API route that already does useful work, but somebody still has to remember to call it. This guide uses Crontap MCP from any supported AI client to turn that route into a reviewed recurring HTTP request. You will choose the endpoint, method, cadence, and timezone, preview three runs, create one schedule, and verify its first real outcome. Crontap owns the HTTP clock. The AI client is the management surface, not the process that wakes up later.
Before you start
- Connect a supported client from the Crontap MCP hub, then confirm
list_schedulesworks. - Deploy a public HTTP or HTTPS endpoint and call it manually before scheduling it.
- Decide what makes a repeated call safe: an idempotency key, unique business date, upsert, lock, or reconciliation query.
- Keep authorization values out of prompts. Add them on the Crontap schedule page after creation.
- Verified against the Crontap MCP guide and public API documentation on 2026-09-15.
Define the API outcome before the cadence
Write down five non-secret facts: the production URL, HTTP method, desired result, local-time or elapsed-time cadence, and timezone. “Refresh the partner catalog every weekday at 07:30 in Europe/Paris” is actionable. “Run the sync regularly” leaves too much for an assistant to guess.
Step 1
Check the endpoint contract
Confirm the exact route and method from code or API documentation. Use POST
for a route designed to trigger work, not because scheduled jobs always use
POST. Verify authentication failure returns a non-2xx status and a repeated
authorized call does not duplicate the business effect.
Step 2
Preview the cadence without writing
Ask for preview_schedule with plain English and an explicit IANA timezone.
Review the returned cron, timezone, description, and three upcoming runs. If
the preview asks a clarification question, answer it and preview again. If it
rejects the cadence, stop instead of inventing a cron expression.
Use only Crontap MCP. Preview "weekdays at 07:30" in Europe/Paris. Do not create or update anything. Show the resolved cron, timezone, description, and three upcoming runs.Step 3
Create one non-secret schedule
Ask for a schedule named weekday partner catalog refresh targeting
https://api.example.com/jobs/partner-catalog. Set the method to POST and
use the previewed cadence. Review the URL, method, cron, timezone, and label
before approving create_schedule. The expected result is one schedule ID,
its status, and upcoming runs.
Create one POST schedule named "weekday partner catalog refresh" for https://api.example.com/jobs/partner-catalog using the cadence we previewed. Repeat the non-secret URL, method, cron, timezone, and label before requesting approval. Do not include Authorization or another secret.If the endpoint is protected, open the returned schedule on the Crontap schedule page and add the Authorization header value there. MCP schedule list and get results deliberately omit request headers and bodies, so an assistant cannot read the saved secret back. Test the endpoint from the schedule page after the value is stored.
Step 4
Read back the exact resource
Ask the assistant to list schedules, select the new ID, and call
get_schedule. Check URL, method, cadence, timezone, label, and status. Do
not approve an update merely because a similarly named resource appears. Pause
the exact ID before correcting a material mismatch.
Step 5
Verify history and business evidence
After a scheduled run, call get_schedule_history for that ID. Compare its
start time, HTTP status, duration, attempt, and run ID with application logs.
Then inspect the output the route was meant to create: a refreshed timestamp,
imported row count, generated file, or sent message.
Prompts for creation and verification
Keep each prompt at one trust boundary. Preview is a read. Creation is one reviewed write. Verification returns to reads.
List schedules, retrieve the exact ID returned for "weekday partner catalog refresh", and read its latest history. Report only the saved non-secret configuration plus startedAt, statusCode, ok, statusText, durationMs, runId, and attempt. Do not modify the schedule.The assistant may return fewer fields when the API has no value for one of them. It must not claim that history includes response bodies, request headers, DNS traces, or application logs. Those are not part of the MCP history contract.
Make a repeated request boring
Schedulers, retries, tests, and humans can all produce another call. A robust endpoint treats a repeat as reconciliation, not another irreversible action. For a daily digest, use the recipient and business date as a unique key. For catalog refresh, upsert the source version. For billing, process outstanding records and record provider event IDs rather than blindly incrementing balances.
An Idempotency-Key header can help only when the endpoint actually stores and enforces it. A static key on every run may incorrectly collapse all future work, while a client-generated random key may not deduplicate a retry. Prefer a key derived from the business window or an application-side uniqueness constraint.
What successful verification proves
A history row with ok=true and a 2xx statusCode proves that Crontap received an HTTP success response. A 2xx does not prove business work completed: the catalog may be unchanged, the email may not have arrived, or an asynchronous queue may still be running. Use the history timestamp or runId to find the corresponding application log, then verify the business record.
No history after the expected time points first to schedule status, cadence, timezone, or the selected schedule ID. A 401 or 403 points to endpoint authentication. A 429 points to rate limiting. A 5xx points to the destination service. A history result without an HTTP status can indicate transport trouble, but application or platform logs are still needed to identify DNS, TLS, connection, or timeout detail.
Troubleshooting
The assistant chooses a method for you
Stop and check the endpoint contract. Crontap supports common HTTP methods, but your route defines which one is valid and whether it has side effects.
The plain-English cadence is ambiguous
Include a clock time, days, and IANA timezone. Preview again and inspect all three upcoming runs before creating anything.
Creation returns the wrong resource
Use the returned opaque ID, not a label search alone. Retrieve it and pause that exact ID while you inspect the mismatch.
The first run returns 401
The MCP connection worked, but the destination rejected the scheduled request. Compare the secret stored in the Crontap UI with the endpoint environment without placing either value in chat.
History is successful but nothing changed
Follow the request into application logs and business storage. The route may acknowledge work before completion, catch an error, or decide there was nothing to process.
Next steps
- Diagnose outcome fields with Debug a failed HTTP cron job with AI.
- Make local-time intent explicit with Timezone-safe recurring jobs.
- Use Scheduled tasks for AI-built apps for more endpoint patterns.
Ready to schedule the API call? Free forever tier. No credit card. Create your Crontap account →
Verified against current Crontap MCP and public API contracts on 2026-09-15. Sources: Crontap MCP guide and Crontap public API.
FAQ
Scheduled API call questions
- Can AI schedule an API call without writing code?
- Yes. A supported MCP client can preview and create a Crontap HTTP schedule. You still need a deployed endpoint and should review every write before approval.
- Should the scheduled API use GET or POST?
- Use the method your endpoint contract defines. POST is common for work-triggering routes, while GET should remain safe and free of side effects.
- Does a 2xx history result prove the job completed?
- No. It proves the endpoint returned an HTTP success response. Check application logs and the resulting database, file, message, or business record for completion.
- Where should an API authorization value be configured?
- Create the non-secret schedule first, then add the Authorization header value on the Crontap schedule page. Keep it out of prompts and MCP tool arguments.