> ## Documentation Index > > Fetch the complete documentation index at: https://lithi.ai/llms.txt > > Use this file to discover all available pages before exploring further. --- title: Trigger Compute from your own scheduler description: >- Run Compute from the orchestrator you already use. It calls the Work API as a trigger client with a bounded key, and never becomes a second authority over your workflow. route: /docs/compute/automation/customer-schedulers page_id: docs-compute-automation-customer-schedulers page_type: howTo content_layer: guided documentation surface_profile: guided_docs audience: Platform teams driving Compute from an existing orchestrator voice: D reader_question: Can I keep my own scheduler and still run Compute work from it? primary_action: Receive events with a verified webhook source_locale: en-US source_status: APPROVED source_version: docs-compute-automation-customer-schedulers-en-us-2026-09-05-v1 last_updated: '2026-09-05' robots: index claim_registry_pinned: true claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write" --- ## Before you start You need an orchestrator you already operate, a workflow that runs correctly by hand, and an automation identity scoped to that one workflow. You do not need to move your scheduling into Compute. Keeping it where your team already watches it is usually the better choice. ## Your orchestrator is a client, not an authority An external scheduler decides when to ask. It does not decide what is admitted, what it costs or whether it may run. Those decisions stay with the workflow authority on the Compute side, every time, for every occurrence. Your orchestrator submits a request and reads a typed answer back. This split is what keeps two systems from disagreeing about the same run. There is one place where a job becomes real, and it is not your scheduler. Mint the narrowest key for it, as described in [how to scope an automation key](/docs/compute/access/api-keys). ## Use a bounded work key The key your orchestrator holds is a work key. It carries work scopes only, and it can quote, run, submit a batch, check status and fetch a result. It cannot administer anything. Management operations, finance and identity administration are a separate family with separate authentication, and those scopes are never mintable on a work key. Give the key one project, one workflow and one spend ceiling if your account structure allows it. A trigger client that can only do one thing is a trigger client you can leave running. ## Carry your own occurrence identity Your scheduler already knows what it intended to run and when. Turn that into a stable occurrence identity and send it with every submission. Derive the identity from the intended occurrence, never from the retry attempt. Your orchestrator will retry, and every retry must present the identity of the occurrence it is retrying. Then read the response to find out what happened. An exact replay returns the prior result; a new identity creates new work and a new charge. The response tells you which one you got. ## Publish a tested, versioned subset Do not hand your team a general-purpose wrapper around everything. Publish the small set of calls you have actually tested against a named client release. State four things next to each published example. Name the client and version you tested, the operations it covers, the operations it excludes, and the workflow release it targets. When you upgrade a client, re-test the subset before you widen it. A subset you have proven is worth more to your team than a surface you have only compiled. ## Confirm success Trigger one occurrence from your orchestrator and follow it through. You should see one quote, one admitted job and one result, with the identity you sent. Then force a retry inside your orchestrator. A correct integration returns the earlier result and creates no second job. Check the spend read-back afterwards. One occurrence should have moved it once. ## When a submission is refused Refusals from a trigger client are typed, and they are not interchangeable. Read the reason and the next action together. - A perimeter load-shed refusal means slow down and retry with backoff. - A request-authority refusal is about your key or account, so fix the grant rather than retrying harder. - A budget refusal means your spend authority is exhausted. Renew it. - A capacity refusal is about this moment only. Retry later, unchanged. Never collapse these into a single retry rule. Two of them get worse if you retry immediately, and two of them are not about timing at all. [Receive events with a verified webhook](/docs/compute/automation/webhooks)