Cloudinary ingestion, identifiers and asset lifecycle
Separate the uploaded asset from its delivered variants
A media application has an original asset, identifiers and metadata, transformations and delivered representations. Cloudinary’s resource type and delivery type have different roles: an image/video/raw classification is not an access-control decision. A public identifier helps address an asset in its relevant namespace; it is not a secret that proves a user may see private content. Folder behavior depends on the actual fixed/dynamic folder model, so moving a Media Library asset folder must not be assumed to rewrite every public delivery identifier.
Control direct uploads deliberately
A browser can upload through an appropriately restricted unsigned preset or use a supported signed workflow prepared by a trusted backend. Do not place an API secret in client code. Cloudinary’s documented authentication-signature algorithm signs the specified serialized parameters using its secret-appended hashing procedure; calling every such signature an HMAC is incorrect. Use the official SDK or exact current algorithm for the actual operation. A digest helper returns a signature value, not necessarily a complete upload URL or an unrestricted authorization to change other parameters.
Understand preset and processing scope
An upload preset groups relevant defaults and restrictions under the supported model. Incoming transformations can alter the stored original representation, whereas eager transformations prepare derived variants under their processing options. Asynchronous processing can finish later, so the initial accepted result does not prove every required derivative is ready. Webhook notifications need verification and idempotent handling under the documented event model. They are evidence about particular events, not permission to trust arbitrary inbound requests.
Govern organization and deletion
Tags, contextual values and structured metadata have different purposes and validation. Metadata may contain personal or operational information and needs intentional access and retention. Search, collection and library interfaces support organization under actual available features; a plan name or historical add-on is not a universal current entitlement. Replacing an asset, deleting it and invalidating delivered caches are separate lifecycle concerns. A deleted original may leave cached representations available for some time unless the appropriate supported access and invalidation design is used. This written practice performs no upload, deletion, metadata change or webhook action and does not assert a current certification prerequisite or booking format.