Skip to content

Add support for create_cloud Provisioning API - #447

Open
const-cloudinary wants to merge 3 commits into
masterfrom
feature/create-cloud-provisioning
Open

Add support for create_cloud Provisioning API#447
const-cloudinary wants to merge 3 commits into
masterfrom
feature/create-cloud-provisioning

Conversation

@const-cloudinary

@const-cloudinary const-cloudinary commented Aug 17, 2026

Copy link
Copy Markdown
Member

Brief Summary of Changes

Adds cloudinary.provisioning.create_cloud(), which creates a Claimable Cloud via the public, unauthenticated POST provisioning/clouds endpoint. Unlike create_agent_account, the returned credentials work immediately; the response also carries a claim_url and a fixed 24h expiry. Media delivery is restricted to an IP allow-list until a human claims the cloud.

  • cloudinary/provisioning/account.py — adds CLOUDS_SUB_PATH and create_cloud(), next to its sibling create_agent_account.
  • cloudinary/provisioning/__init__.py — exports create_cloud.
  • test/test_provisioning_api.py — adds CreateCloudTest (mocked transport).

What does this PR address?

  • GitHub issue (Add reference - #XX)
  • Refactoring
  • New feature
  • Bug fix
  • Adds more tests

Are tests included?

  • Yes
  • No

Reviewer, please note:

  • delivery_ips is optional, and omitting it is the recommended call. The API appends the requester's own resolved address, so create_cloud() with no arguments is the normal path; the parameter exists to allow delivery from hosts other than the caller.
  • Creation only. The endpoint supports only POST — delivery IPs cannot be changed after creation. Getting them wrong is unrecoverable for that cloud (remedy: create another, or claim it), so please don't expect retry/repair helpers.
  • The IP restriction is delivery-only: the Upload and Admin APIs authenticate by signature and are not restricted by it, so it is not a confidentiality control. The docstring says so explicitly.

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I ran the full test suite before pushing the changes and all the tests pass.

Note on the last box: the provisioning tests pass and the full-suite result is unchanged from the pre-change baseline (local failures are all Must supply cloud_name from no CLOUDINARY_URL configured) — this change introduces no new failures.

🤖 Generated with Claude Code

const-cloudinary and others added 3 commits August 17, 2026 17:32
Creates a Claimable Cloud via the public, unauthenticated
POST provisioning/clouds endpoint, returning credentials that work
immediately along with a claim URL and a 24h expiry.

- `delivery_ips` is optional: omit it and the server derives the media
  delivery allow-list from the requester's own resolved address, which is
  more reliable than detecting it client-side behind a VPN or pooled egress.
- Sent as a genuine array rather than via `encode_list`, since the server
  rejects a comma-joined string with `delivery_ips must be an array`.
- The response is returned verbatim (flat, unlike the nested shape of
  `create_agent_account`), so added fields reach the caller intact.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Replace realistic-looking cloud name, API key and secret placeholders with
clearly synthetic values, so the fixtures cannot be mistaken for real
credentials.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Accept optional `agent_framework`, `agent_llm_model`, `agent_goal` and
`sdk_framework`, matching the fields `create_agent_account` already takes.
All are omitted from the request when unset.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant