TL;DR: A portfolio API lets you build a gallery site that maintains itself. With Playbook, you create a board, batch-load images straight from their URLs, then either publish the board as a hosted page or fetch its assets and render your own frontend. Add work, reorder it, swap a hero shot, and every surface updates. No rebuild. No redeploy. No touching the codebase. You get boards, one-call publishing, live iframe embeds, and permanent CDN URLs for every image. Curate once, and the portfolio keeps itself current.
A portfolio is a content problem wearing a design problem's clothes
A living portfolio separates the work you curate from the site you ship, so adding a project never means editing code. Most portfolio sites hardcode the gallery: a new piece means resizing images, editing an array, committing, and redeploying. That is fine at three projects and miserable at thirty. Move the content into a Playbook board and the render layer stops caring how many pieces you have or what order they sit in. Your files are a living, breathing thing. Your site should reflect that.
Curate a board, then choose how it renders
With Playbook you curate a board once, then decide whether Playbook renders it for you or hands you the assets to render yourself. There are two paths off the same board. Publish it, and Playbook serves a polished, branded gallery page (custom slug, logo, cover) with nothing for you to host. Or go headless: fetch the board's assets, read the display_url CDN field on each one, and drop them into your own React, Astro, or plain HTML frontend. Want it inside an existing marketing site? Embed the board as a live iframe, carousel or gallery, that stays in sync. Browse real gallery examples on the photo gallery page.
What powers it
- Create the portfolio container:
POST /v1/{org}/boards - Load work straight from image URLs:
POST /v1/{org}/assets/batch_create_from_urls - Publish a hosted, branded gallery:
POST /v1/{org}/boards/{board}/publish - Fetch assets for a custom frontend:
GET /v1/{org}/boards/{board}/assets - Render images anywhere: the
display_urlCDN field on every asset, plus permanent permalink URLs - Embed on any site: a live iframe (carousel or gallery) that refreshes with the board
The board is the source of truth, so editing it is the deploy
Because every surface reads from the same board, editing the board is the deploy. The published page, the iframe embed, and your custom frontend all pull from one place. Reorder assets, add a new shoot, retire an old one, and the change propagates everywhere at once. There is no second copy to keep in sync and no build step between you and a live update. The full walkthrough, with request and response bodies, lives in the portfolio example in the Playbook API docs.
FAQ
What is a portfolio API?
A portfolio API is an interface for building a gallery site from data instead of hardcoded markup. Playbook's REST API exposes boards, assets, publishing, and CDN URLs, so you curate work in one place and render it as a hosted page, an embed, or your own frontend.
Do I need to redeploy when I add new work?
No. Your site reads from a Playbook board, so adding, reordering, or removing assets updates the published page, the embed, and any custom frontend automatically. Editing the board is the deploy.
Can I use my own frontend instead of the hosted page?
Yes. Call GET /v1/{org}/boards/{board}/assets, read the display_url CDN field on each asset, and render them in React, Astro, or plain HTML. You control the markup, and Playbook stays the content layer.
Which plan includes API access?
REST API access is available on Playbook's paid plans. At the time of writing, API call quotas begin on Pro and full API and SDK access is listed on Business and up, so check the current pricing page before you build.
Ready to build a portfolio that runs itself? Schedule a demo and see the Playbook API in action.