Who this is for
A founder, operations lead or technical contact who runs a scheduled script or function that pulls records from another system and acts on them.
Some records are never processed, others are processed twice, or both happen after a run was interrupted or the other system was slow.
The result
Against a synthetic copy of the API, the job processes each of 120 synthetic records over three pages once in effect, picks up a late-arriving record whose timestamp is older than the previous run but inside the overlap window, and loses none and duplicates none when it is killed before any one of its steps (reading a page, acting, recording the key, saving the checkpoint) and then restarted.
What is included
- One scheduled job against one HTTPS API whose documentation describes a way to list records by modification time or stable order, with paging
- A persisted checkpoint, an overlap window and complete paging, with the order act (safe to repeat for the same key), then record the key, then advance the checkpoint
- The action made idempotent by record key (for example create-or-update on the key, or a destination that accepts an idempotency key), or the action's result and the handled key written to one store in one transaction
- A durable record of handled record keys, with the agreed rule for a changed record and a stated retention that covers the overlap window and the longest gap between runs
- A synthetic stand-in for the API and automated tests for paging, late arrival, repeat, kill-at-every-step and error cases
You receive
- The job's source code in a repository you control, with a readme and a configuration list that names no secret values
- The synthetic API stand-in and the automated test suite, including the kill-at-every-step test
- A run log from the kill, late-arrival and repeat tests
- A short design note on the checkpoint, the overlap size chosen and why, the key and retention rule, and what the job cannot promise
What is not included
- Deploying or scheduling the job in production, which stays with your team
- Subscribing to webhooks or building a receiver, which is a different outcome
- More than one API or one action, a historical backfill beyond one agreed window, or buying higher rate limits
- Monitoring or alerting after hand-over, unless you buy a separate service
- An action that is one-way and cannot be made safe to repeat by key: after a crash it forces a choice between a possible repeat and a possible loss, and this fixed job does not make that choice for you
- Real customer data in tests, or calls to the real API with real credentials by us
What we need from you first
- A link to the API's public documentation for listing records, including its paging and rate-limit sections
- What the job does with each record, in a sentence, and how often it should run
- Where the job runs today, and what has gone wrong: missing records, repeated records or both
- Do not send API keys, customer data or source code in the first enquiry
Never send passwords, keys, customer records or confidential code in the first enquiry. Secure handover is agreed after scoping.
How we check it is done
- Against the synthetic stand-in holding 120 records over three pages, one run reads every page and leaves exactly one effect at the destination for each of the 120 keys.
- A record created after the poll started, with a timestamp older than the previous run but inside the overlap window, is processed once on the next run.
- When the job is killed before each of its steps in turn (reading a page, acting on a record, recording its key, saving the checkpoint) and then restarted, every one of the 120 keys ends with exactly one effect: none missing, none doubled.
- A record returned in two consecutive polls is acted on once, and an error partway through a run leaves the checkpoint behind the first unrecorded record.
- The design note states the key rule, the retention of handled keys, the overlap chosen and the limits: a record appearing later than the overlap, or an action that cannot be made safe to repeat, is not covered.
You run the automated tests and review the evidence, then sign off before payment. Your team deploys and schedules the job and checks one live run under your own keys.
When we would stop or decline
- The API offers no usable ordering, filter or unique key, so complete polling cannot be shown
- The action is one-way and cannot be made safe to repeat by key or written in one transaction with the handled key. A crash between acting and recording then forces a choice between a possible repeat and a possible loss; this fixed job does not cover it, and we quote a different scope with that choice written down
- The only test route would call the real API with live customer data
Questions
Why not just ask for records since the last run time?
A record can appear late, sit on a later page, or be read twice around an overlap. A single timestamp loses or repeats such records. The job keeps an overlap and a record of handled keys.
Can you guarantee nothing is ever missed or done twice?
Not in general. We show the behaviour against a synthetic stand-in built from the API's documentation, at every stop point, and state the overlap and the assumptions. The result is one effect per record key when the action is safe to repeat for that key; where it is not, no polling design avoids a choice between a possible repeat and a possible loss. The live API's behaviour is yours to confirm.
Is this for Zapier or Make?
No. Those tools manage their own polling triggers. This job is for a script or function that you run yourself.
Price and terms
From £645 · untested offer price. After the agreed checks pass and you sign off. No advance payment.
This is a new service with no published client results. The price is a starting point we have not yet tested with buyers. Nothing is ordered or charged by the enquiry. The full specification is on the Synthetic Industry catalogue.