canonical: https://jentic.com/apis/redhat.com/pulp-3

# Redhat Pulp 3 API

The Pulp 3 API runs Red Hat's Pulp content platform, which fetches, uploads, organises, and distributes software packages across RPM, container, Python, file, npm, Maven, Ruby gem, and Hugging Face repositories. Repositories sync from remotes into immutable repository versions, content is added or removed through modify calls, and publications are served to clients through distributions at a base_path. Long-running work such as a sync returns a task that can be inspected or cancelled, and content guards, roles, signing services, exporters, and importers control access and movement between Pulp instances.

## For AI agents

Sync RPM, container, Python, and other package repositories from remotes, upload and add packages, publish and distribute repository versions, and track the resulting Pulp tasks.

## Scope

Does not build packages, run CI pipelines, or execute containers. Use for storing, syncing, publishing, and distributing package repositories in Pulp only.

## Capabilities

- Sync an RPM repository from a remote with mirror and sync_policy options, then follow the returned task
- Upload an RPM package as multipart form data and add or remove content units in a repository with modify
- Publish a repository version and serve it through a distribution at a chosen base_path
- Define remotes with url, policy, TLS certificates, proxy settings, and a rate_limit for upstream downloads
- Search RPM packages by name, arch, version, release, or sha256 using filters such as name__startswith
- Inspect or cancel long-running tasks, and clean up orphaned content after removals
- Grant roles on a repository, distribution, or remote and list the current user's permissions on it

## Use cases

### Repository maintenance agent through Jentic

A platform agent keeping internal mirrors current needs to trigger syncs and confirm they finished, without a human running pulp CLI commands. Through Jentic the agent searches for 'sync a Pulp RPM repository', loads the sync operation with its input schema, and posts it against the repository href with the chosen remote while the credential is injected at call time. The call returns a task href the agent polls until the task completes, then reports the new repository version.

Example prompt: POST {rpm_rpm_repository_href}sync/ with the remote href and mirror false, then poll GET {task_href} until state reports completed and return the created repository version

### Publish a new RPM build

When CI produces an RPM, the release step uploads it, adds it to the repository, and republishes so clients see it. Pulp accepts the package through the RPM upload operation as multipart data, adds content units to a repository through modify, creates a publication from the new repository version, and points a distribution with a name and base_path at that publication.

Example prompt: POST `/api/pulp/{pulp_domain}/api/v3/content/rpm/packages/upload`/ with the RPM file, POST {rpm_rpm_repository_href}modify/ with add_content_units, then POST `/api/pulp/{pulp_domain}/api/v3/publications/rpm/rpm`/ for the repository

### Package inventory search

Security and release teams need to know which builds of a package are stored. The RPM package list accepts filters such as name, name__startswith, arch, version, release, and sha256, and can be narrowed to a repository_version, so a query can find every stored openssl build for x86_64 or confirm a checksum is present.

Example prompt: GET `/api/pulp/{pulp_domain}/api/v3/content/rpm/packages`/ with name 'openssl' and arch 'x86_64', then list the version and release of each result

### Upstream remote configuration

Mirroring an upstream repository starts with a remote. Creating an RPM remote requires a name and url, and accepts a download policy, TLS client certificates, proxy credentials, timeouts, download_concurrency, and a rate_limit so the mirror does not overload the upstream. A repository created with that remote can then sync on demand.

Example prompt: POST `/api/pulp/{pulp_domain}/api/v3/remotes/rpm/rpm`/ with name 'baseos-mirror', the upstream url, and policy 'on_demand', then POST `/api/pulp/{pulp_domain}/api/v3/repositories/rpm/rpm`/ with name 'baseos' and that remote

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `{rpm_rpm_repository_href}sync/` | Sync an RPM repository from a remote |
| POST | `/api/pulp/{pulp_domain}/api/v3/repositories/rpm/rpm/` | Create an RPM repository |
| POST | `{rpm_rpm_repository_href}modify/` | Add or remove repository content |
| POST | `/api/pulp/{pulp_domain}/api/v3/content/rpm/packages/upload/` | Upload an RPM package |
| POST | `/api/pulp/{pulp_domain}/api/v3/publications/rpm/rpm/` | Create an RPM publication |
| POST | `/api/pulp/{pulp_domain}/api/v3/distributions/rpm/rpm/` | Create an RPM distribution |
| GET | `/api/pulp/{pulp_domain}/api/v3/content/rpm/packages/` | List RPM packages |
| GET | `{task_href}` | Inspect a task |

## Key resources

- **Repositories** — RPM, container, Python, file, npm, Maven, gem, and Hugging Face repositories with sync, modify, and versioning
- **Remotes** — Upstream sources with URL, download policy, TLS, proxy, and rate limit settings
- **Content** — Packages, container blobs, manifests, tags, signatures, and OpenPGP keys, searchable with field filters
- **Publications and Distributions** — Published repository versions served to clients at a base_path, optionally behind content guards
- **Tasks** — Asynchronous work such as syncs and publishes, listed, inspected, and cancelled
- **Access control** — Roles, groups, users, access policies, and per-object permissions

## AI readiness

This API is usable in Jentic One now. Its AI-readiness score against Jentic's framework shows where it stands today and where improvements would make it even easier for agents to use.

- **Score:** 43 / 100
- **Maturity:** Non-Ready
- **Dimensions:**
  - Foundational Compliance: 25 / 100
  - Developer Experience & Jentic Compatibility: 56 / 100
  - AI-Readiness & Agent Experience: 50 / 100
  - Agent Usability: 43 / 100
  - Security: 48 / 100
  - AI Discoverability: 65 / 100
- **View full report:** https://jentic.com/apis/redhat.com/pulp-3/scorecard
- **How the score is calculated:** https://docs.jentic.com/reference/api-readiness-framework/overview/
- **More about the dimensions:** https://docs.jentic.com/reference/api-readiness-framework/specification/#dimensional-model-overview

### Score it yourself

Every API in the directory is allowlisted, so you can re-score it with no key required.

- **Score your own API:** https://jentic.com/scorecard.md
- **Scoring CLI agent skill:** https://github.com/jentic/jentic-api-scorecard/blob/main/skills/jentic-api-scorecard/SKILL.md

```sh
npx @jentic/api-scorecard-cli score <openapi-url>
```

## Why Jentic

- **Setup:** Wiring Pulp by hand means choosing between Basic, a sessionid cookie, and OAuth2 client credentials against Red Hat SSO, building href-based URLs for every object, and polling task hrefs for each asynchronous call. Through Jentic you install once, import Pulp 3 from the API Directory, store the credential once, and your agent calls it.
- **Permission scoping:** Pulp places the domain in the path (`/api/pulp/{pulp_domain}/...`) and addresses each repository, remote, and task by an href that is itself the URL path, so a rule can bound your agent to one domain or one repository's operations. You choose the operations it may call, so destructive ones like repository deletion or orphan cleanup are not included unless you add them.
- **Credential handling:** Your Pulp credential is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'sync a Pulp RPM repository' or 'upload an RPM package', and Jentic returns the matching Pulp operation with its input schema, so the agent finds the right one among hundreds without browsing the reference.

## Related APIs

- **AWS CodeArtifact** — Managed package repositories for npm, PyPI, Maven, and more on AWS
- **Quay Frontend** — Container image registry
- **PyPI API** — Python Package Index metadata
- **Docker Engine API** — Build, pull, and run containers on a Docker host

## FAQ

### What authentication does the Pulp 3 API use?

Per its OpenAPI spec, every operation accepts any one of three schemes: HTTP Basic, a sessionid cookie, or OAuth2 client credentials against Red Hat SSO with the api.console scope. For agent use, Basic or a client-credentials token is the practical choice. Through Jentic the credential is stored by your own instance and attached at call time.

### How do I know when a Pulp sync has finished?

Sync, publish, and modify calls return HTTP 202 with a task href rather than finishing inline. Poll GET {task_href} to read the task state and the resources it created, such as the new repository version, and use PATCH {task_href} to cancel a task that should not continue.

### What are the rate limits for the Pulp 3 API?

The OpenAPI spec does not specify request rate limits for the API itself. Its rate_limit field applies to remotes, capping how fast Pulp downloads from an upstream. Check the Pulp documentation at https://pulpproject.org for server tuning guidance.

### Is there a Pulp MCP server?

You don't need an MCP server to give your agent Pulp. Jentic connects it directly from the API Directory: import it, store your credential once, and your agent finds the sync, upload, and publish operations it needs on demand instead of loading hundreds of tool definitions into its context.

### How do I sync an RPM repository through Jentic?

Search Jentic for 'sync a Pulp RPM repository', load the POST {rpm_rpm_repository_href}sync/ operation, and run it with the repository href and a remote href. Then poll the returned task until it completes. To run it on your own infrastructure, install Jentic One from its GitHub repo.

### Which content types does this Pulp API cover?

The spec includes repositories for RPM, container, Python, file, npm, Maven, Ruby gem, and Hugging Face content, plus OpenPGP keyrings. Each type has its own remotes, repositories, and in most cases publications and distributions.

### Can I limit what my agent is allowed to do with the Pulp 3 API?

Yes. As an example, allow only POST on one repository's sync path and GET on task hrefs, so the agent can refresh that mirror and check progress but cannot delete repositories, remove content, or clean up orphans, and every call is logged.