Skip to main content
Capell home
Live demo

Manage cookie preferences

Choose which optional cookies Capell may use.

Essential
Always on

Required for Capell to work — login, security, page rendering.

Analytics

Anonymous usage telemetry to improve editor performance.

Marketing

Personalization for the Capell marketing site.

Cookie policy

Name every consumer before removing the API

Capell does not provide a delivery API. Plan a coupled migration only when the Laravel website can own delivery and every independent consumer has a supported destination or a deliberate retirement decision.

One app, not two Keep your structure Delivery you control
CMS capture · Content index Structured content stays visible in the admin. The screenshot comes from the Capell CMS admin, where page records, preview images, layouts, SEO status, and editor actions stay visible without opening every page.
Public output: cache hit Public HTML stays separate from the admin. This anonymous frontend capture proves the output boundary: cached public HTML with no editor selectors, model identifiers, or signed authoring URLs.
CMS capture · Site health Operational health is part of the CMS workflow. This real Capell CMS capture shows launch and operations checks for cache, generated output, queues, scheduler health, and deployment readiness.

Actual Capell CMS pages index showing records, SEO overview metrics, thumbnails, layouts, and editor actions.

What normally transfers

Entries, content models, assets, locales, taxonomies, metadata, references, and URL records can usually be exported. The content-model owner decides how remote schemas map to pages, reusable records, or application-owned data.

What needs mapping or rebuilding

The API consumer owner inventories every website, application, feed, partner, and build process. The webhooks and query assumptions owner records SDK versions, filters, pagination, draft access, locale fallback, schema expectations, retries, build triggers, and downstream jobs.

What may not transfer cleanly

Provider-specific references, deeply nested content, unpublished states, asset transforms, and webhook order may need bespoke work. The multi-channel dependency owner must approve a destination or retirement plan for each consumer because Capell does not provide a delivery API.

Verify URLs and search metadata

For the Laravel website, inventory routes, metadata, canonicals, languages, media, sitemaps, and redirects. For every other consumer, verify the fields and behaviour its current query contract provides before changing the source.

Run a representative pilot

Move one content model with linked records, assets, locales, preview, webhook effects, and a query used by a real consumer. The editor acceptance owner tests drafting and preview; consumer owners compare outputs; the technical owner checks public HTML, logs, jobs, and rollback.

Plan cutover and rollback

The cutover owner defines the content freeze, final export, credential changes, webhook pause, route switch, consumer release order, monitoring window, and go or no-go decision. Keep the headless service readable and recoverable until every named consumer passes verification.

Do not remove a valuable API simply to reduce the number of systems. Proceed only when the inventory proves the Laravel site can own delivery and the migration removes more coordination than it creates.

Migration map

Map contracts before moving entries

Cover the content model, API consumers, webhooks and query assumptions, assets, editor acceptance, multi-channel dependencies, and cutover. On a small team, one person may cover several responsibilities; none of the checks should disappear.

2 keep 4 replaced by Capell 3 to decide

  1. In your headless stack Content entries In Capell Records in your Laravel database Capell replaces

    Headless exports are vendor-specific. Migration Assistant supports mapped CSV or XML imports into Capell; relationships, assets, routes, and preview assumptions still need an explicit source-to-target map.

    Open Migration Assistant

  2. In your headless stack Your frontend components In Capell The same markup, fed by Blade or Livewire Keep

    Design systems and component markup may carry over when they already belong to Laravel. An independent frontend that requires the vendor API needs its own replacement decision; Capell does not supply that API.

    Explore delivery

  3. In your headless stack API calls and SDK glue In Capell Direct data access in one app Capell replaces

    Page data comes from the CMS runtime in the same codebase, so the fetch wrappers, retry logic, and cache-invalidation glue around the content API can be retired.

  4. In your headless stack A separate frontend deployment In Capell One Laravel deploy Capell replaces

    One repository, one pipeline, one place to look when something breaks. Routing, policies, tests and deployment stay in the Laravel project your team controls.

    For developers

  5. In your headless stack Preview tokens and preview builds In Capell Drafts and previews in the admin Capell replaces

    Editors preview unpublished work inside the Filament workspace, with no token wiring or preview deployment to keep alive.

  6. In your headless stack Webhooks and build triggers In Capell Laravel events and jobs, where still needed You decide

    Triggers that only existed to rebuild the frontend go away. Hooks that other systems depend on need a new home in Laravel events, jobs, or scheduled commands.

  7. In your headless stack Asset CDN or DAM In Capell Capell media, or the setup you already trust You decide

    Media can move into Capell records, or stay on the current CDN with Capell storing references. Volume and team workflow decide.

  8. In your headless stack Translation vendor workflow In Capell Language variants stored in the CMS You decide

    Capell holds per-language content and paths. If a vendor pipeline feeds translations today, plan the handoff format before the move.

  9. In your headless stack Your domain and URLs In Capell The same public routes Keep

    Canonical paths, redirects, and sitemap output move under your control in Laravel, and existing addresses can be preserved and verified.

Role scenarios

What to inspect before migrating

Checks for mapping, redirects, media, integrations, cutover, recovery, and ownership.

Role-based checks drawn from product capabilities and fit boundaries.

Site owner representing this editorial scenario.

The cleanup was part of the plan — what to verify

Dry-run an import, inspect its field map, then edit one imported record before testing rollback. The process should skip bad items, preserve redirects and refuse to erase the later edit.

Read more

A credible evaluation should confirm: Old permalinks are redirected to their new destinations during import, so existing inbound links and search rankings continue resolving after cutover. A re-import must also preserve corrections already made to migrated pages.

When to look elsewhere: A tiny, tidy source can still be faster to re-key by hand than to map. Site owners would only lean on this when there is real structure worth carrying across, and site owners would still keep a developer close.

Site Owner

Evaluator scenario for a site owner

Questions

Questions every API consumer owner must answer

Which consumers prevent the delivery API from being retired?
Capell does not provide a delivery API. Content and public rendering move into the Laravel application that owns the website. Tour Capell
Can the current frontend stay?
Yes, when it is already a Laravel frontend. Replace remote content calls with hydrated Capell render data and keep the presentation code in the app. View themes
What happens to content models?
Map remote schemas into Capell page types and package-owned records. A developer still defines the Filament schemas; editors do not create arbitrary models. See owner fit
What should move first?
Start with one content type, its media, URLs, preview, and publishing path. Prove the coupled render before migrating the remaining collections. Explore features
Loading footer