CapaEvery team, brand and site.
Under control.
Capa serves published content from the nearest edge, scopes each person to the work that is theirs, and keeps a record of every publish. Talk to us about running it across your company.
- < 3 sFrom Publish to live, measured
- 20–50 msA typical cached read, from the nearest edge
- Per modelWho may edit, and who may publish
- Versioned APIA dated version never changes shape
Fast for visitors.
Calm for the people behind it.
Six reasons teams with many people, brands and sites choose Capa.
Served from the nearest edge.
Every publish in seconds.
Published content is served from the nearest of Fastly's edge locations, typically in 20 to 50 ms, over REST or GraphQL. A publish purges only the entries and models it touched, and readers keep getting the last copy while the edge refreshes. If the origin has a bad minute, the edge keeps serving the last good copy.
- Live 2 to 3 seconds after Publish, measured.
- No rebuilds, and no ISR to tune.
A request log: reads answered from the edge cache, typically in 20 to 50 ms, and a publish that purges only the keys it changed.
Everyone gets exactly
the access they need.
Start people from four roles, then narrow each one to the projects, models and actions their work needs. Publishing is a separate permission from editing, and billing and invitations can stay with your admins.
- Integration secrets stay sealed, even from admins, until an owner grants them.
- API keys with scopes, allowed origins, expiry, and rotation with a grace window.
- Revoke access and it applies on that person’s very next request.
Writes and publishes for Europe. Reads the US site, changes nothing there.
- EU siteEdit and publish
- US siteRead only
- ModelsRead only
- API keysNo access
- BillingNo access
Every change
leaves a trail.
Every save is a version of the entry, with who made it and when. Settings, Publishing lists every scheduled, running, finished and failed publish, grouped by the action that created it, with the attempts behind each one.
- Word-level diffs on the Publish page before anything goes out.
- A failure surfaces the next morning, in the log and on the bell, with Retry.
- A discarded draft stays in the entry’s history.
AI that stays inside
each person’s scope.
The Assistant works with the access of whoever is asking. An editor on one site gets drafts on that site, and an admin can ask across all of them. Content changes wait as drafts on the Publish page, and model changes run only once someone approves the plan.
- Nothing it writes goes live on its own.
- The same roles and grants your people have, with no separate AI permissions to keep in step.
“Update the returns policy to 60 days.”
Ana Ruiz
Drafted the new returns policy on the UK site. The other two sites are outside your access, so I left them alone.
- UK site: Returns policyDraft
Maya Lindqvist
Drafted the new returns policy on all three sites. They are waiting in Publish for review.
- UK site: Returns policyDraft
- US site: Returns policyDraft
- Shop: Returns policyDraft
Upgrades happen
on your schedule.
Our releases never change a live integration. Each one stays on the API version it was built on until your team decides to move, and we never retire a version while you are still calling it.
- Every version lists exactly what it changes.
- Deprecated GraphQL fields are flagged in every response that uses them.
- Old versions keep working for as long as you use them.
Capa-Version: 2026-10-01- 2026-10-01Your site runs on this version.
- Next versionMove when you are ready.
We never retire a version you are still calling.
A project per brand.
One login across them.
Run each brand, market or site as its own project with its own models, keys and people, or feed several sites from one project with a key per site. People sign in once and see only the projects they belong to.
- Hand a project to its new owner when a team or an agency changes hands.
- Keys read only their own project’s content.
- Pages
- Products
- Stores
cap_live_…a91cPeople- Maya LindqvistAdmin
- Ana RuizContent
- Pages
- Products
- Stores
cap_live_…40e7People- Maya LindqvistAdmin
- Leo ParkContent
- Jobs
- Teams
cap_live_…7d22People- Maya LindqvistViewer
- Priya NairAdmin
From the first call
to launch day.
- 1
Tell us what you run
Use the form below: what you publish, how many teams, brands and sites, and what you use today.
- 2
Map it together
A working session with your developers and editors. Projects, models, roles and keys, laid out on Capa before anyone commits.
- 3
Build on it for real
Your team builds on a real project from the first day. Capa is free to start, so nothing waits on paperwork.
- 4
Agree terms, then launch
Support, an uptime commitment and invoicing go into one agreement, and we stay close through your launch.
What your agreement covers
- A security reviewSend us your questionnaire. We answer it, and walk your team through how keys, roles and content are handled.
- An uptime commitmentWritten into your agreement, with how it is measured.
- Support with set response timesA direct line to the people who build Capa, with response times agreed in your contract.
- Terms and invoicingAnnual terms and payment by invoice, to fit how your company buys software.
How fast is Capa under real traffic?
Can we control who publishes, model by model?
What happens to our integrations when the API changes?
Can we run several brands, regions or sites?
Can we see what changed, and who changed it?
We work with an agency. Does that fit?
How do we start?
Tell us what
you are building.
A few lines are enough. We will reply to plan a first call with the people who build Capa.
Good to have on the call
- How many people edit content, and in how many teams.
- The sites, apps and screens that read it.
- What you use today, and what is getting in the way.