Toggle dark mode

Public Upload in Content Hub

Content Hub excels at user management and Single Sign-On (SSO) integration. However, there are situations where allowing public uploads, without creating user accounts, might be more practical. This could be due to financial constraints, the need for faster onboarding of external contributors, or even facilitating easier asset delivery by agencies. Fortunately, Content Hub's flexible integration capabilities allow making this happen with relative ease.


While uploading assets to Content Hub is straightforward using the Upload API v2, a few key aspects deserve attention before scoping out the application:


The out of the box three stage workflow (Created, In Review, Approved) works great when using the Content Hub UI. However, as the uploader doesn't have access to Content Hub, if left as-is the assets are likely to get 'lost' in the Created state. A separate process for dealing with publicly uploaded assets should be developed.

Recommendation: Add a new boolean member to the M.Asset definition to indicate whether the asset was uploaded publicly. Then, create a new page, similar to the out of the box 'Create' page that shows all assets which have this member set to true and are in the Created state. Allow content librarians access to this page to populate the assets data and submit them for approval.

Integration Permissions

Following the principle of least privilege, the application used for public uploads should have minimal permissions. This should primarily focus on uploading assets and potentially updating some data to flag them as publicly uploaded.

The minimum permissions required for this are:

M.AssetM.Final.Lifecycle.Status = Created Created by current userUpdate
M.Asset, M.FileCreated by current userRead, Create


The application will also need to have some level of security applied to it - despite Content Hub's built in virus scanning technology, it would be dangerous to allow completely unfiltered access to upload assets. Some form of DDoS protection is also advised.

Recommendation: Create a new entity definition, linked to M.Collection, to hold access keys, with an expiry date. From a collection page a user can then create an access key entity which is then used to generate a URL to the upload application. The URL should contain the access key as part of the path, which is then validated by the application before allowing uploading assets directly into the specific collection.

Public Upload Application

To demonstrate this functionality, I’ve developed a Next.JS application - it's really just a UI wrapper around the Upload API v2, with an additional post-upload step to update the description of the asset indicating where it was uploaded from, and a new IsPublicUpload property to true.

The public upload application in use.

The provided code for this application can be found on GitHub. Feel free to submit Pull Requests (PRs) for any enhancements you think could be useful!

Important: The provided application is a proof of concept and lacks robust security features. It should not be used outside a controlled environment without significant modification.


Enabling public uploads via an integration application to Content Hub offers a valuable tool for specific use cases. Explore the code on GitHub and consider collaborating on further improvements. I'd love to hear from you! Share any alternative approaches you've implemented for public uploads in Content Hub, or if you have questions about this approach.