Contentstack, Amplience, and Contentful

See’s Candies: Legendary Brand, Classic Problem

You know the brand, you probably know the box. See’s Candies is chocolate royalty. Founded in 1921, still run out of California, still oozing the same black-and-white nostalgia that somehow triggers everyone’s inner six-year-old the moment they see it. Warren Buffett calls See’s the “prototype of a dream business”. Show me another legacy confectioner with more than 200 shops, a seat at the Berkshire Hathaway meeting table, and a product with cult status.

But “classic” only gets you so far on the web. The digital world keeps moving, and the longer you run your business on an old e-comm foundation, the more you feel it. SiteGenesis was a powerhouse in 2014 but a potential burden in 2024. The See’s team had experts and grit, but reality was setting in: new features were getting harder, speed and innovation were falling behind, and SFRA looked like yesterday’s upgrade by the time they considered it. Nobody wants to pour money into tech that's already gliding into technology history.

What See’s Wanted

See’s didn’t just want a new shipping label slapped on the same box. They came to 64labs with three non-negotiables:

• Modernize the full e-commerce experience.
• Achieve real, measurable site performance gains.
• Build a flexible system to speed up innovation, not slow it down with vendor dependencies.

In plain English: stop playing defense and start building for whatever’s coming next.

The 64labs Playbook: Composable Storefront Done Right

Here’s where we tore up the old script. Forget incremental upgrades and sticking plasters on brittle architecture. 64labs delivered a ground-up composable SFCC storefront, with Amplience front and center as the first-ever headless CMS in the See’s stack. Multi-site, no extra partners tagging along, and all about future-proofing, not just fixing.

• Timeline: Six months from kick-off to site go-live. No “phase two” delays, no endless sign-offs.
• Integration: Amplience as the content engine, fully decoupled, giving content teams more power and site managers the flexibility every digital leader wants.
• Transition: No retraining disaster, no operational hiccups. See’s own team kept the keys. The platform was designed so they’d build on it, not constantly call us to patch holes.

As any seasoned tech leader will tell you, there’s no such thing as instant magic with a major platform shift. The early days after launch were a gradual climb, not a spike, but by month three, performance stats came right in line with what we expect from composable builds: bounce rates settling down by about 20%, conversions ticking up on mobile by about the same amount, and stability returning for peak traffic surges.

Why This Project Actually Mattered

Here’s the part nobody says out loud: digital transformation is as much about team empowerment as it is about shiny new tech. See’s leapfrogged the incremental, skipped the “safe” path that would have kept legacy quirks clinging on, and jumped into an architecture meant to help them adapt quickly. They got full ownership, no added complexity, and the freedom to build at their own pace.

Most importantly, See’s didn’t have to become a new company overnight. There wasn’t a giant consulting army or a risky vendor swap. It was their internal team plus 64labs, in a partnership that extended beyond “launch” to a real, ongoing roadmap for modernizing the rest of the digital ecosystem. That’s composable done the right way.

The Bottom Line

Your legacy doesn’t have to slow you down. See’s Candies looked at the same crossroads every heritage brand faces and decided to skip a generation instead of waiting to play catch-up. They built something future-proof - so now, they can move at a speed that matches the brand’s ambition.

That is what a composable strategy should look like. Not just shiny tech for a press release. A platform you own, a team that’s empowered, and a path cleared for whatever is next.

{{banner}}

SCAPI vs. OCAPI: Which Salesforce Commerce API Really Matters for 2025?

You keep hearing these acronyms, SCAPI and OCAPI, tossed around as if everyone knows what they are and how they are different. But for most e-commerce teams trying to modernize, the only thing clear about Salesforce Commerce APIs is the confusion. So let’s clear it up, focusing on actual trade-offs and numbers where they exist, minus any of the sales fluff or alphabet soup.

What is OCAPI, Really?

OCAPI, or Open Commerce API, is the original integration workhorse behind Salesforce Commerce Cloud. It’s been in the wild for more than a decade. Most legacy Salesforce storefronts use OCAPI for everything from simple cart adjustments to full-scale inventory syncs. The API is built on REST principles, allows deep access to data, and splits up functionality into Shop, Data, and Meta endpoints. In plain words, OCAPI lets you manipulate almost every piece of business logic tied to your store, including custom hooks unique to your implementation.

Here are some real-world numbers: OCAPI currently supports thousands of production storefronts and, according to public developer forums, processes millions of daily requests across various Salesforce clients. Most companies running integrations built prior to 2020 almost certainly depend on OCAPI somewhere in their stack. Flexible permissions, robust access controls, and years of documentation make it relatively straightforward if not always future-proof.

But it is slowing down. Salesforce has officially said that there will be no new development for OCAPI beyond bug fixes. If you are waiting for innovation here, you will be disappointed. 

What is SCAPI and How is it Different?

SCAPI, or Salesforce Commerce API, is the answer to the demands of a more modern approach to commerce, specifically, the need for agility, speed, and “headless” builds where front-end and back-end systems run distinct from each other. Salesforce began rolling out SCAPI in 2020 to support cloud-native architectures and composable commerce. Unlike OCAPI, SCAPI is focused on two core areas: Shopper APIs designed for everything customer-facing, and Admin APIs which power the tools merchants use every day.

Let’s talk numbers. According to Salesforce product update notes, SCAPI now handles over 70 percent of all new API-powered store projects launched on Salesforce Commerce Cloud. Performance tests published by Salesforce show that SCAPI endpoints routinely deliver sub-150ms API response times at scale, especially when using their web-tier caching and built-in personalization logic. This directly impacts cart and product browsing speed, which is one of the drivers behind higher conversion rates in modern storefronts. That isn’t always what you will see with heavier customization in the mix - which means most of the time - but SCAPI is definitely fit for composable purpose.

Because SCAPI integrates natively with Salesforce’s broader ecosystem, it supports single sign-on through OAuth2, allows for granular analytics via built-in dashboards, and keeps up with the rapid pace of business changes. According to Salesforce, there have been over 200 feature releases and improvements to SCAPI since 2021 alone. To a degree that reflects how new it is, but we would expect SCAPI development to get faster rather than slower as SFCC refocuses energy on B2C on SFCC in the coming months. SCAPI is the future of Salesforce Commerce Cloud.

So Where Should You Focus?

For teams managing legacy storefronts or deep customizations glued together with years of OCAPI work, there is no burning platform. It will all still work for the foreseeable future. OCAPI will keep doing its job for now, though the clock is ticking. If your store processes 10,000 orders a day and has six different ERP systems in the mix, you probably still need OCAPI’s mature endpoints and flexibility for edge case handling.

On the other hand, if you are starting a fresh project, re-platforming, or want to build for where commerce is headed, SCAPI is an urgent next step on the commerce roadmap. It is the only API that will get new features, performance improvements, and long-term support. SCAPI is the better fit for sites expecting to support multiple front-ends (think web, app, or social commerce), and it is built for scalability. Salesforce claims SCAPI can scale to thousands of concurrent shoppers with minimal tuning. But I believe you could call that a forward looking statement.

A few cautionary numbers: Some highly specialized OCAPI features still are not available in SCAPI as of mid-2025, so double check your requirements before committing fully to the newer API. For most standard commerce workloads, though, Salesforce is closing the gap fast. They are clearly signaling that within another year, all critical functionality will be available in SCAPI.

What About Hybrid and Migration Scenarios?

You are not locked in. Salesforce supports running both APIs in parallel so you can modernize piecemeal. This is especially useful for retailers who cannot afford big-bang migrations. In practice, teams often start by building new headless front-ends with SCAPI while leaving legacy business integrations running on OCAPI. Over time, more endpoints are migrated as the new APIs catch up and as custom logic is untangled from previous implementations.

Final Thoughts

If you only remember two things: OCAPI is solid as a rock, but just as motionless - it ain’t getting any better.  SCAPI is modern and evolving fast and has increasing development effort by SFCC behind it. Ignoring SCAPI in a new build means missing out on performance lifts, monitoring tools, and composable commerce support. 

Which of them you use will make less difference than the quality of your composable or API build. Clean, unified data and flexible infrastructure will have a bigger impact on your actual speed and innovation than obsessing over acronyms. Figure out what processes you need to modernize and then choose (or retain) the API architecture that actually fits that need. 

{{banner}}

Your Digital Team is Better Than Your Tech Stack

Marketers and merchandisers in enterprise retail are often stuck in a weird paradox: they have powerful ideas, agile teams, and massive goals, but a tech stack that moves like it's 2012. If launching a promo takes 3 JIRA tickets and 2 weeks of dev time, you're not just behind, you're bleeding money.

Enter composable commerce: a modular, API-first approach to building digital storefronts. While it sounds like a developer’s dream (and it is), the biggest wins actually show up for marketers and merchants.

Here’s how.‍

1. You Can Get Sh*t Done Fast

Composable means your frontend is decoupled from your backend. So when merch or marketing wants to:

• Launch a campaign,

• Update a product carousel,

• Swap out homepage banners for seasonal offers,

• Build a landing page for that influencer collab…

...they can do it without dev involvement (or with minimal support). Teams can use low-code/no-code tools integrated into the stack (like CMSs or visual merch tools) to make changes in hours, not weeks. And dev teams, before you get too upset, these guys have been using tag managers and personalization tools behind your back to do things they shouldn't for about 10 years now. This is better-safer-transparenter than that.

Result: Faster go-to-market, more A/B testing, more wins.

2. Personalization and Segmentation Actually Work

Legacy monoliths often treat personalization like a bolt-on feature, not a core capability. Composable stacks let you plug in best-in-class personalization engines (we have hard-core expertise in or Dynamic Yield) that actually talk to your content and commerce layers in real-time.

Marketers can then:

• Target based on customer behavior, not just segments

• Trigger experiences dynamically

• Swap components (not entire pages)

Now, it better be built correctly by a partner who knows what they are doing. (cough). And that partner better be in the weeds with your team on what it has to do where (double cough). And you better be willing to out some work into making it work rather than think it automagically improves conversions (whooping cough). But a composable architecture does unlock all this.

Result: Better CX, higher conversion rates, more data to refine.

3. You Own the Brand Experience, Not the Platform

Composable gives you control over your frontend experience. Sure you have, like templates with like Bootstrap n stuff that you can play with. But repeat after me - ISML is DISML. With composable you are a world of React and Typescript and kittens. You get to control how the site looks, feels, and behaves instead of being locked into the templates someone thought were state of the art back in 2014.

This means your brand team can:

• Tell a story that actually feels premium

• Maintain consistency across channels

• Create immersive content experiences

…without getting a “that’s not possible with our CMS” reply from IT.

Result: Experience-driven commerce, not catalog-driven commerce.

4. Operational Flexibility = Less Burnout

Move fast and break stuff they say. Yeah, great advice for a 20 year old building an app no one wil likely ever have to use. We don;t get that luxury. Marketers and merchandisers are constantly caught between "move fast" and "absolutely don’t break stuff."

Composable gives us a middle ground:

• You can make changes and roll something back within about 10 seconds.

• Repair or update to one part of the site does not have to impact another. And you will have built testing and QA workflows to automatically make sure that is the case. Or at least you will if you use 64labs (cough - sorry I can't quite get rid of this).

• You can schedule campaigns without syncing 5 different systems. Decide on your preferred workflow, how the various elements need to work together. And build that. Composable is made to compose.

• You can preview content as it will actually appear — not just in staging environments that look nothing like the real site.

Result: Less stress, more autonomy, more velocity, more control.

5. No More Big Bang

Worried about an old school Big Bang launch of composable? Don't be. You can put a full composable site out to a subset of users for as long as you want before you have to commit? Don’t be. Most enterprise teams go with a split launch - maybe 5% of users to start. They iron out any kinks. Then when they realize how much the ROI will be if they switch over like right now, they switch.

You can go incremental of course.

You can plug in a headless CMS (like Contenstack or Amplience), run it headlessly within your legacy stack for a while, and prove ROI before ripping anything out. Or un composable with a new CMS in one region for six months to give yourselves some experience of both before rolling out globally.

Result: Low risk, high reward — easy to minimize risk and you keep IT on your side.

In a world where campaigns move at the speed of culture and conversion windows last minutes, composable lets marketers and merchandisers do what they do best: create, launch, measure, and optimize without waiting for devs, approvals, or outdated systems to catch up.

{{banner}}