Create a schedule

Creates a schedule and returns it together with its first planned occurrence. Give exactly one of at, delaySeconds, everySeconds and cron. An optional partitionKey selects a fairness lane inside this project and environment; it is fixed after create. Add a verified endpoint to deliver each occurrence there. Instead of endpoint, give a url: the service uses this project and environment's existing endpoint at exactly that address, or creates one silently. Its signing secret is never returned; the response's endpointSigningSecret says where a signed-in member reveals it. Reusing an endpoint needs only schedules:write; creating one also needs endpoints:write, and without it the request is refused as scope_missing. Optional JSON data is encrypted before PostgreSQL persistence, placed in the signed callback, and returned as given by a schedule read. Optional http selects POST (default), PUT, or bodyless GET and schedule header overrides. Omitted HTTP settings preserve the signed structured envelope; body: { mode: 'json', value: ... } sends that JSON directly without interpolation. Ordinary headers remain readable and secret values are encrypted and write-only. Schedule headers override endpoint defaults case-insensitively, with suppress to omit an inherited header and remove to resume inheritance. Product signing, content and transport headers are reserved. Raw JSON and GET carry asynchronous completion details in reserved Callback-Completion headers. at and delaySeconds fire once; a delay is converted to an absolute instant when the request is accepted, so a schedule created either way reads back the same afterwards. everySeconds is a fixed duration and its first occurrence falls one interval after acceptance — it stays the same length across a daylight-saving change, and takes no timezone for that reason. cron is a wall clock: it is read against the IANA timeZone sent with it, UTC when none is, and the first occurrence is the first instant the expression names after acceptance. Where the clocks go forward and the wall time named does not exist that day, the occurrence falls at the first instant after the gap; where they go back and it happens twice, it falls once, at the earlier of the two. A recurring schedule is materialized one occurrence at a time: the next one is planned once the current one is due, so a read always shows one occurrence still to come. lateness.policy decides what happens when an occurrence reaches its first attempt after its planned instant: skipAhead never carries a recurring arrival across its next scheduled instant (and a shorter custom window may retire it earlier), while catchUp admits one arrival within maxStalenessSeconds even after later recurrence instants passed. A one-shot has no next recurrence, so either explicit policy uses its window and the default is catchUp with 24 hours; recurring schedules default to skipAhead, and a catchUp without an override has a one-interval window. A retry already in progress is exempt because it arrived and failed; its retry and give-up policy still decide the outcome. The organization, project and environment come from the verified principal; a body cannot name them, and the endpoint must belong to the same tuple, so a credential issued for one project can only ever create schedules in that project. Send an Idempotency-Key to make a retry safe: the identical request returns the schedule that key already created, marked Idempotency-Replayed: true, and creates nothing further; the same key with a different request is refused idempotency_key_reused. A replay reports the schedule as it stands now, not a frozen copy of the first response — if it was paused in between, the replay says so. Some calls need more: endpoints:write is required as well when the request names a url this project and environment has no endpoint at yet, and the call is refused scope_missing without it.