Skip to content
Cloud infrastructure/devops

redhat.local:patchman-engine

Patchman-engine sandbox and mock API

API of the Patch application on [cloud.redhat.com](cloud.redhat.com) Syntax of the `filter[name]` query parameters is described in [Filters documentation](https://github.com/RedHatInsights/patchman-engine/wiki/API-custom-filters) Writes persist, data moves on a schedule and every change can fire a signed webhook.

Operations
21
Collections
-
Event types
-
Start this simulation
example request
curl https://your-redhat-local-patchman-engine.slurry.io/api/patch/v1/advisories \
  -H "Authorization: Bearer slurry_sim_..."

Your simulation gets its own hostname, key and IP allow-list. Built from API version v1.15.3.

What gets simulated

Collections, relationships and state machines are worked out from the spec when you start the simulation.

  • State. Creates, updates and deletes persist and show up in later reads.
  • Behaviour. Records move through their states on a schedule you control, and you can fast-forward up to 30 days.
  • Webhooks. Every change emits a signed, retried event.
  • Failure. Per-endpoint errors, latency and chaos rules, on demand.

Operations

First 12 of 21.

  • GET/api/patch/v1/advisories
  • GET/api/patch/v1/advisories/{advisory_id}
  • GET/api/patch/v1/advisories/{advisory_id}/systems
  • GET/api/patch/v1/export/advisories
  • GET/api/patch/v1/export/advisories/{advisory_id}/systems
  • GET/api/patch/v1/export/packages
  • GET/api/patch/v1/export/packages/{package_name}/systems
  • GET/api/patch/v1/export/systems
  • GET/api/patch/v1/export/systems/{inventory_id}/advisories
  • GET/api/patch/v1/export/systems/{inventory_id}/packages
  • GET/api/patch/v1/packages/
  • GET/api/patch/v1/packages/{package_name}