public

Enqueue a job

Requires write. Enqueues import or enrichment.

The other three job types are refused with a 400 that names the route to use instead, and not for security reasons — a key with write can already do more than any of them. Each would be a button that does nothing:

  • recipe_build / recipe_rebuild_all — recipe execution is not implemented. The processor used to sleep three seconds and mark the job completed with pagesGenerated: 0; that pretence was removed and it now refuses, so enqueueing one from here would reintroduce the same lie one layer up. GET .../recipes/{recipe} executes a recipe and returns the matches.
  • media_process — the media processor never updates its job row, so the row would sit at queued for ever whatever the work did. POST .../media/{assetId}/reprocess does this properly.

Queue routing and retry policy are shared with the admin surface rather than reimplemented, so the two cannot drift on which queue a type lands in.

post/public/v1/directories/{directory}/jobs

Request

  • Base URL: https://api.epicdirectories.com
  • URL: https://api.epicdirectories.com/public/v1/directories/{directory}/jobs
  • Auth: API key in header x-api-key

Path parameters

directorystring required

Headers

Idempotency-Keystring

Optional. Send a unique key per logical operation to make retries safe. 1-256 characters, and only letters, digits, - and _ — colons and other separators are rejected with 400. A retry with the same key replays the original response (status + body) instead of re-executing. Cached for 24h. Reusing a key with a different request body returns 409 — note that a timestamp in the body (e.g. fetchedAt) turns an otherwise-stable key into a permanent 409, so either omit it (snapshots default it server-side) or fold a payload digest into the key. Skipped on 5xx responses (transient errors should be retried fresh).

x-api-keystring required

API Key for authentication

Request body

jobType'import' | 'enrichment' required

Type of job. media_process, recipe_build and recipe_rebuild_all exist on the operator API but are refused here — each would be a button that does nothing, and the 400 names the route that actually does the job.

inputobject

Job input, passed through to the processor. Shape depends on jobType — an import wants { config: { listingType, ... } }. Validated by the processor rather than here: inputJson is stored as sent, so a malformed input surfaces as a job that fails with a reason rather than a request that 400s and leaves no record.

Response

Job created and queued

Changes

No recorded changes to this operation across all 1 revision of this API.