canonical: https://jentic.com/apis/openstack.org/openstack # OpenStack Swift Object Storage API Jentic publishes the only available OpenAPI specification for OpenStack Swift Object Storage API, keeping it validated and agent-ready. Swift is OpenStack's distributed object storage service, organising data into accounts containing containers, which in turn hold objects. The REST API supports object PUT/GET/DELETE, container management, large object uploads, bulk delete, ACLs, and metadata, and authenticates with a Keystone token in the X-Auth-Token header. ## For AI agents Upload, list, retrieve, and delete objects in OpenStack Swift containers using a Keystone authentication token. ## Scope Does not handle compute provisioning, networking, or block storage volumes - use for Swift account, container, and object operations only. ## Capabilities - Upload objects of arbitrary size into a named container - List containers in an account and objects within a container - Retrieve and update container and object metadata - Delete objects individually or in bulk via the bulk-delete query - Inspect cluster capabilities and supported middleware via /info - Authenticate every request with a Keystone token in X-Auth-Token ## Use cases ### Self-hosted backup target for application data An operations team uses an in-house OpenStack deployment as the backup target for application snapshots, writing each snapshot as a Swift object inside a per-day container. Swift's ACLs and account quotas let the team isolate backups per service without leaving the private cloud, and bulk-delete cleans up expired retention windows in one call. Example prompt: PUT a tar.gz to `/v1/{account}/backups-2026-06-10/{object}`, then issue a bulk-delete against the previous month's container. ### Static asset hosting from Swift A platform team serves static assets out of Swift containers via a CDN, with each tenant's content in its own account/container. The metadata endpoints let the team set cache headers and ACLs per object so assets are cacheable for the public while bucket configuration stays on the storage side. Example prompt: PUT an image to `/v1/{account}/{container}/{object}` with X-Object-Meta-CacheControl, then GET the same object and confirm the metadata. ### Lifecycle cleanup with bulk delete A data engineering team runs scheduled cleanup against a large Swift container by collecting expired object names and submitting them to `/v1/{account}/{container}`?bulk-delete in one call. This avoids per-object DELETE round trips and keeps cleanup jobs within their maintenance window. Example prompt: POST a newline-separated list of object names to `/v1/{account}/{container}`?bulk-delete and verify the response reports zero errors. ### Agent-driven private-cloud storage through Jentic An AI ops agent that triages incidents archives evidence (logs, packet captures) into a Swift container via Jentic. Jentic isolates the Keystone token rotation, so the agent only ever has scoped tool access to the Swift operations rather than the long-lived auth credentials. Example prompt: Search Jentic for 'upload an object to OpenStack Swift', load PUT `/v1/{account}/{container}/{object}`, and execute it with the evidence file. ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | `/info` | Discover cluster capabilities and limits | | GET | `/v1/{account}` | List containers in an account | | PUT | `/v1/{account}/{container}` | Create or update a container | | GET | `/v1/{account}/{container}` | List objects in a container | | PUT | `/v1/{account}/{container}/{object}` | Upload an object | | GET | `/v1/{account}/{container}/{object}` | Download an object | | DELETE | `/v1/{account}/{container}/{object}` | Delete an object | ## Key resources - **Account** — Top-level tenant scope containing containers - **Containers** — Group objects under an account - **Objects** — Individual stored files with metadata - **Bulk operations** — Bulk-delete across many objects in one call - **Capabilities** — /info endpoint exposing cluster middleware and limits ## Why Jentic - **Setup:** Wiring the OpenStack Swift API by hand means resolving your Swift endpoint, obtaining a fresh X-Auth-Token from Keystone for each call window, and threading the account, container, and object path segments through every request. Through Jentic you install once, import the OpenStack Swift API from the API Directory, store the Keystone credentials once, and your agent calls it. - **Permission scoping:** Swift puts the container in the URL path (`/v1/{account}/{container}/{object}`), so a rule can pin your agent to one container: it can read and write objects there and nothing else. You choose the operations it may call, so object deletion is not included unless you add it. - **Credential handling:** Your OpenStack Keystone credentials are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'upload an object to OpenStack Swift' or 'list containers in an account', and Jentic returns the matching Swift operation with its path parameter and metadata-header schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **AWS** — Amazon S3 object storage as the public-cloud equivalent of Swift - **Backblaze B2 API** — Low-cost public cloud object storage with an S3-compatible surface - **Open Policy Agent (OPA) REST API** — Authorize Swift container and object access with Rego policies ## FAQ ### Why is there no official OpenAPI spec for OpenStack Swift Object Storage API? OpenStack Swift does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call OpenStack Swift Object Storage API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer. ### What authentication does the OpenStack Swift API use? Swift uses a Keystone authentication token passed in the X-Auth-Token header. Through Jentic, the long-lived Keystone credentials sit in the encrypted vault and Jentic obtains and rotates the per-request token, so the agent only handles scoped tool access. ### Can I bulk-delete objects with the Swift API? Yes. POST a newline-separated list of objects to `/v1/{account}/{container}`?bulk-delete and Swift returns a summary of successes and failures. This is much faster than issuing per-object DELETE calls during lifecycle cleanup. ### What are the rate limits for the OpenStack Swift API? Because Swift is self-hosted on each operator's OpenStack cluster, rate limits depend on the cluster's middleware configuration (notably ratelimit middleware) rather than a vendor quota. Inspect /info to see which limits the cluster enforces. ### How do I upload an object through Jentic? Run pip install jentic, search 'upload an object to OpenStack Swift', load PUT `/v1/{account}/{container}/{object}`, and execute it with the file body and the right account/container path. Jentic supplies the X-Auth-Token header from a refreshed Keystone token. ### Why is the base URL a placeholder? Swift runs as part of an operator's OpenStack deployment, so the spec uses {swift-endpoint} as a server variable. Set it to your cluster's Swift proxy URL (for example, https://swift.cloud.example.com) when configuring the operation. ### Can I limit what my agent is allowed to do with the OpenStack Swift API? Yes. Because you run Jentic One yourself and write the rules, you decide which Swift operations your agent may call and which stored Keystone credentials it may use. Since Swift puts the container in the URL path (`/v1/{account}/{container}/{object}`), a rule can pin the agent to a single container so it only reads and writes objects there. Object deletion and bulk-delete stay off unless you explicitly grant those operations.