Connect FlutterFlow to Salesforce Commerce Cloud (SFCC) using mandatory Firebase Cloud Function proxy to handle SLAS OAuth 2.0 token minting. The Cloud Function authenticates via PKCE guest or registered shopper sessions and returns short-lived Bearer tokens. FlutterFlow API Calls then query SCAPI Shopper endpoints for products, search, and basket management — with token refresh logic to handle short expiry mid-session.
| Fact | Value |
|---|---|
| Tool | Salesforce Commerce Cloud |
| Category | E-commerce |
| Method | FlutterFlow API Call |
| Difficulty | Advanced |
| Time required | 2-3 hours |
| Last updated | July 2026 |
FlutterFlow as a Mobile Storefront for Salesforce Commerce Cloud
Salesforce Commerce Cloud is an enterprise commerce platform used by major global retailers. Its headless architecture — built around the Salesforce Commerce API (SCAPI) — makes it possible to power a custom native mobile storefront built in FlutterFlow, where FlutterFlow handles the UI and SCAPI handles products, search, basket management, and checkout orchestration.
The authentication story is where SFCC differs significantly from simpler e-commerce APIs. SCAPI uses the Shopper Login & API Access Service (SLAS) — an OAuth 2.0 system that issues short-lived shopper access tokens. These tokens come in two varieties: guest shopper tokens (for anonymous browsing, no login required) and registered shopper tokens (for logged-in customers with persistent baskets and order history). Both token types are obtained via PKCE-based OAuth flows that require a client ID and — for admin operations — a client secret. These credentials must NEVER appear in a FlutterFlow API Call or Custom Action, because they would be compiled into the distributed Flutter app. A Firebase Cloud Function serves as the mandatory authentication gateway: it holds the SLAS credentials securely in environment variables, runs the OAuth flow, and returns only the short-lived shopper access token to FlutterFlow.
This integration is genuinely Advanced difficulty. You need Salesforce org access to obtain the SFCC organization ID, shortcode, SLAS client ID, and Business Manager access to configure API access. There is no public free tier — SFCC is sold on enterprise contracts, though Salesforce provides sandbox environments for development. Before starting any FlutterFlow work, confirm with your Salesforce team or partner that you have the necessary SFCC access and that SLAS is configured for your org.
Integration method
FlutterFlow connects to SFCC through two tiers: a Firebase Cloud Function handles SLAS OAuth 2.0 authentication and mints short-lived shopper Bearer tokens, while FlutterFlow API Calls query SCAPI Shopper endpoints (product search, product detail, basket) using those tokens. SLAS client credentials and client secrets never reach the Flutter client — they live exclusively in the Cloud Function environment.
Prerequisites
- Salesforce Commerce Cloud org access — obtain your org ID (organization ID), shortcode, and SLAS client ID from your Salesforce partner or SFCC Business Manager
- SLAS configured in SFCC Business Manager — the SLAS application must be set up with your redirect URIs and scopes before you can mint tokens
- A Firebase project on the Blaze plan with Cloud Functions enabled — required for the SLAS OAuth proxy and for outbound HTTPS calls
- A FlutterFlow project (any tier) with Firebase connected via Settings & Integrations → Firebase
- Familiarity with OAuth 2.0 concepts (authorization codes, PKCE, access tokens, refresh tokens) — this is not a beginner OAuth integration
Step-by-step guide
Gather your SFCC credentials from Business Manager
Before writing any FlutterFlow or Cloud Function code, you need four pieces of information from your Salesforce Commerce Cloud environment. These are available in SFCC Business Manager and from your Salesforce partner or admin. First: your Organization ID — a string that looks like f_ecom_XXXX_XXX and identifies your SFCC org. Second: your Shortcode — a short alphanumeric string that forms part of the SCAPI base URL (your SCAPI base will be https://{shortcode}.api.commercecloud.salesforce.com). Third: your SLAS Client ID — registered in Business Manager under Administration → SLAS Administration → Client Registry. Fourth: your Site ID — the specific storefront site within your org (e.g. RefArch or your custom site ID). If you're using PKCE guest flow only (no registered shopper login), you do NOT need a client secret. If you're building a registered shopper flow, you'll also need the client secret — store this in Firebase Functions environment variables, never in FlutterFlow. Verify your SLAS client is configured with the correct redirect URI for the Cloud Function — for guest PKCE, this can be any HTTPS URL since there's no browser redirect in the server-side flow. Double-check that the required API scopes (sfcc.shopper-products.rw, sfcc.shopper-baskets-orders.rw, etc.) are granted to your SLAS client. These configuration steps happen entirely in SFCC Business Manager and Salesforce's identity management — no FlutterFlow or Firebase work yet.
Pro tip: SCAPI and legacy OCAPI have completely different authentication paths and endpoint structures. This tutorial uses SCAPI + SLAS — do not mix in OCAPI documentation or endpoints, as they require different auth and have different response schemas.
Expected result: You have your SFCC org ID, shortcode, SLAS client ID, and site ID noted and ready to configure in the Cloud Function.
Deploy a Firebase Cloud Function for SLAS token minting
The SLAS OAuth flow involves generating a PKCE code verifier and challenge, calling the SLAS authorize endpoint, exchanging the authorization code for a token, and managing token expiry and refresh. None of this can happen in a Flutter client — PKCE code verifiers that reach the client can be intercepted, and any client secret would be exposed in the app binary. Create a Firebase Cloud Function with two HTTP endpoints: one to issue a guest shopper token (/guestToken), and one to refresh an existing token (/refreshToken). Deploy the function with your SFCC credentials set as environment variables in the Firebase Console under Functions → Configuration: SFCC_ORG_ID, SFCC_SHORTCODE, SFCC_SITE_ID, SFCC_CLIENT_ID, and (if using registered shopper flow) SFCC_CLIENT_SECRET. The guestToken endpoint runs the full PKCE guest shopper flow and returns a JSON response to FlutterFlow containing just the access_token and its expires_in seconds. FlutterFlow stores this token in App State and passes it as a Bearer header to all SCAPI calls. The refreshToken endpoint accepts an existing refresh token and returns a new access token — FlutterFlow calls this when the current token is close to expiry or when a SCAPI call returns 401. Test the deployed function by calling the /guestToken endpoint directly in your browser or a REST client — you should receive a JSON response with an access_token field. Copy this token and use it to manually test a SCAPI product search call to confirm it works before wiring up FlutterFlow.
1const functions = require('firebase-functions');2const axios = require('axios');3const crypto = require('crypto');45const ORG_ID = process.env.SFCC_ORG_ID; // e.g. f_ecom_XXXX_XXX6const SHORTCODE = process.env.SFCC_SHORTCODE; // e.g. kv7kzm787const SITE_ID = process.env.SFCC_SITE_ID; // e.g. RefArch8const CLIENT_ID = process.env.SFCC_CLIENT_ID;910const SLAS_BASE = `https://${SHORTCODE}.api.commercecloud.salesforce.com/shopper/auth/v1/organizations/${ORG_ID}`;1112function generatePKCE() {13 const verifier = crypto.randomBytes(32).toString('base64url');14 const challenge = crypto.createHash('sha256').update(verifier).digest('base64url');15 return { verifier, challenge };16}1718exports.sfccGuestToken = functions.https.onRequest(async (req, res) => {19 res.set('Access-Control-Allow-Origin', '*');20 res.set('Access-Control-Allow-Methods', 'GET, OPTIONS');21 if (req.method === 'OPTIONS') { res.status(204).send(''); return; }2223 try {24 const { verifier, challenge } = generatePKCE();25 // Step 1: Get authorization code26 const authResp = await axios.get(`${SLAS_BASE}/oauth2/authorize`, {27 params: {28 client_id: CLIENT_ID,29 channel_id: SITE_ID,30 redirect_uri: 'http://localhost:3000/callback',31 response_type: 'code',32 code_challenge: challenge,33 code_challenge_method: 'S256',34 hint: 'guest',35 },36 maxRedirects: 0,37 validateStatus: s => s === 303 || s === 302,38 });39 const location = authResp.headers['location'];40 const code = new URL(location, 'https://placeholder').searchParams.get('code');4142 // Step 2: Exchange code for token43 const tokenResp = await axios.post(44 `${SLAS_BASE}/oauth2/token`,45 new URLSearchParams({46 grant_type: 'authorization_code_pkce',47 code,48 redirect_uri: 'http://localhost:3000/callback',49 code_verifier: verifier,50 client_id: CLIENT_ID,51 channel_id: SITE_ID,52 }),53 { headers: { 'Content-Type': 'application/x-www-form-urlencoded' } }54 );55 res.status(200).json({56 access_token: tokenResp.data.access_token,57 refresh_token: tokenResp.data.refresh_token,58 expires_in: tokenResp.data.expires_in,59 });60 } catch (error) {61 res.status(500).json({ error: error.message });62 }63});6465exports.sfccRefreshToken = functions.https.onRequest(async (req, res) => {66 res.set('Access-Control-Allow-Origin', '*');67 if (req.method === 'OPTIONS') { res.status(204).send(''); return; }68 const { refresh_token } = req.body;69 try {70 const tokenResp = await axios.post(71 `${SLAS_BASE}/oauth2/token`,72 new URLSearchParams({73 grant_type: 'refresh_token',74 refresh_token,75 client_id: CLIENT_ID,76 }),77 { headers: { 'Content-Type': 'application/x-www-form-urlencoded' } }78 );79 res.status(200).json({80 access_token: tokenResp.data.access_token,81 expires_in: tokenResp.data.expires_in,82 });83 } catch (error) {84 res.status(401).json({ error: 'Token refresh failed' });85 }86});87Pro tip: SLAS guest tokens typically have short expiry (often 30 minutes — verify in your SLAS configuration). Store the expires_in value alongside the token in App State and calculate when to refresh: if the token will expire within the next 5 minutes, call /refreshToken before making SCAPI basket or checkout calls.
Expected result: Both Cloud Functions deploy successfully. Calling /sfccGuestToken returns a JSON response with an access_token, refresh_token, and expires_in value.
Create FlutterFlow API Groups for token exchange and SCAPI calls
With the Cloud Functions deployed, set up two separate API Groups in FlutterFlow to handle the two tiers of the architecture: one for token management via the Cloud Functions, and one for SCAPI Shopper product and search calls. In FlutterFlow, click API Calls in the left nav → + Add → Create API Group. Name it SFCCAuth. Set the Base URL to your Cloud Function base URL (e.g. https://us-central1-your-project.cloudfunctions.net). Add one API Call named GetGuestToken: method GET, endpoint /sfccGuestToken, no headers needed. Add a second API Call named RefreshToken: method POST, endpoint /sfccRefreshToken, Content-Type: application/json header, and a JSON body variable for refresh_token. Create a second API Group named SFCCShop. Set the Base URL to your SCAPI endpoint: https://{shortcode}.api.commercecloud.salesforce.com/commerce/shopper-products/v1 — replace {shortcode} with your actual shortcode value as a hardcoded string (not a variable, since it doesn't change). Add a Group-level header: Authorization with value Bearer {{accessToken}} where accessToken is a variable. Add these API Calls: - SearchProducts: GET /organizations/{{orgId}}/product-search — query parameters: q (search term), limit (20), site_id (your site ID) - GetProductDetail: GET /organizations/{{orgId}}/products/{{productId}} — path variables: orgId, productId; query parameter: site_id In the Response & Test tab for SearchProducts, paste a sample SCAPI search response and click Generate JSON Paths. SCAPI product search responses have a nested structure: $.hits[0].productId, $.hits[0].productName, $.hits[0].price, $.hits[0].image.link — map these carefully as SCAPI's schema differs from simpler REST APIs.
1{2 "API Group SFCCAuth": {3 "Base URL": "https://us-central1-YOUR_PROJECT.cloudfunctions.net",4 "Calls": [5 { "Name": "GetGuestToken", "Method": "GET", "Endpoint": "/sfccGuestToken" },6 { "Name": "RefreshToken", "Method": "POST", "Endpoint": "/sfccRefreshToken",7 "Headers": { "Content-Type": "application/json" },8 "Body": { "refresh_token": "{{refreshToken}}" } }9 ]10 },11 "API Group SFCCShop": {12 "Base URL": "https://YOUR_SHORTCODE.api.commercecloud.salesforce.com/commerce/shopper-products/v1",13 "Group Headers": { "Authorization": "Bearer {{accessToken}}" },14 "Calls": [15 {16 "Name": "SearchProducts",17 "Method": "GET",18 "Endpoint": "/organizations/{{orgId}}/product-search",19 "Query Params": [20 { "name": "q", "type": "String" },21 { "name": "limit", "default": "20" },22 { "name": "site_id", "default": "YOUR_SITE_ID" }23 ]24 },25 {26 "Name": "GetProductDetail",27 "Method": "GET",28 "Endpoint": "/organizations/{{orgId}}/products/{{productId}}",29 "Query Params": [30 { "name": "site_id", "default": "YOUR_SITE_ID" }31 ]32 }33 ]34 }35}36Pro tip: SCAPI product detail responses and product search hit responses have DIFFERENT JSON shapes — a search hit has productId and productName at top level, while a product detail has id and name. Build separate Data Types and JSON Path mappings for each endpoint rather than trying to reuse one Data Type for both.
Expected result: Both SFCCAuth and SFCCShop API Groups appear in the FlutterFlow API Calls panel. GetGuestToken returns a token when tested, and SearchProducts returns SCAPI search results when you pass the token manually in the accessToken variable field.
Implement token storage and refresh in App State
Short-lived shopper tokens are the trickiest part of SFCC in FlutterFlow. The guest token typically expires after 30 minutes (verify in your SLAS configuration), which means a user session lasting longer than that will encounter 401 errors mid-flow — usually at the worst possible moment, such as when adding to basket or initiating checkout. Set up App State variables to manage token lifecycle. In FlutterFlow, click App State in the left nav → + Add State Variable. Create three variables: accessToken (String), refreshToken (String), and tokenExpiry (Integer — Unix timestamp of when the current token expires). On your app's initial page, add an On Page Load Action that calls SFCCAuth → GetGuestToken. In the Action Flow, after a successful response, use Update App State to set accessToken from the response JSON Path $.access_token, refreshToken from $.refresh_token, and tokenExpiry from the current timestamp plus the $.expires_in value (in seconds). Before any SCAPI API Call that touches basket or checkout (which are most sensitive to 401), add a conditional check in the Action Flow: if the current timestamp is within 300 seconds of tokenExpiry, first call SFCCAuth → RefreshToken (passing the current refreshToken App State value), update accessToken and tokenExpiry from the response, then proceed with the SCAPI call. This ensures the token is always valid when it reaches SCAPI. For the SCAPI API Calls, always pass the accessToken App State variable as the accessToken variable in the API Group. The API Group's Authorization header is already set to Bearer {{accessToken}}, so it picks up the current value automatically — you do not need to set the header manually on each call.
Pro tip: If you'd rather not build and maintain the SLAS token refresh logic yourself, RapidDev's team builds FlutterFlow integrations with SFCC regularly and handles the authentication architecture — request a free scoping call at rapidevelopers.com/contact.
Expected result: App State shows accessToken, refreshToken, and tokenExpiry variables. The app correctly requests a guest token on launch, stores it in App State, and refreshes it before basket or checkout operations.
Build product search and detail screens and handle nested SCAPI JSON
Create a ProductSearch page in FlutterFlow. Add a TextField at the top bound to a searchQuery page state variable (String). Add a Search button — in its Action Flow, fire SFCCShop → SearchProducts with q set to the searchQuery variable, orgId from App Values set to your SFCC org ID, and accessToken from App State. Below the search bar, add a ListView. Bind it via Backend Query to SFCCShop → SearchProducts (with a default empty search on page load to show featured products). The SCAPI search response nests hits inside a top-level object — use JSON Path $.hits to get the array. Create a FlutterFlow Data Type called SFCCProductHit with fields: productId (String), productName (String), price (Double), imageLink (String), pageUrl (String). Map the search response JSON Paths: $.hits[0].productId, $.hits[0].productName, $.hits[0].price, $.hits[0].image.link. For the Product Detail page, pass the productId when navigating from the search results (use Navigate action with a parameter). On the detail page, fire SFCCShop → GetProductDetail on page load. The detail response schema is different from the search hit schema — create a separate Data Type SFCCProductDetail with fields: id (String), name (String), longDescription (String), price (Double), primaryImageLink (String), availableColors (List of String). Map the JSON Paths from the actual SCAPI product detail response structure (check the Response & Test panel for the exact paths your org returns). For basket management, note that the Shopper Baskets SCAPI endpoint is at a different API path (/commerce/shopper-baskets/v1) — create a third API Group SFCCBasket for those calls. Basket operations (create, add item, get) require the same accessToken and use the org ID and site ID the same way.
Pro tip: SCAPI may return different product fields depending on which expansion parameters you include in your query. Add the expand query parameter to your GetProductDetail call — e.g. expand=images,prices,variations — to get richer data in a single request rather than making multiple calls.
Expected result: The ProductSearch screen shows SCAPI search results in a ListView with product names, images, and prices. Tapping a result navigates to the ProductDetail screen with the full product information loaded from SCAPI.
Handle token refresh and 401 errors mid-session
Even with proactive token refresh logic (Step 4), edge cases can cause 401 errors from SCAPI — for example, if the app is backgrounded for a long time and the token expires while the app is inactive. Set up a global error handler for SCAPI API Calls that detects 401 responses and triggers a token refresh automatically. In FlutterFlow, for each SCAPI API Call, go to the On Error section of the Backend Query or Action. Add a conditional action: if the error code equals 401, run the RefreshToken API Call (SFCCAuth → RefreshToken), update App State with the new accessToken and tokenExpiry, then retry the original SCAPI call. This retry loop should only execute once — use a retrying Boolean App State variable to prevent infinite 401 loops if the refresh itself fails. For the basket and checkout flow, SCAPI's Shopper Baskets endpoint (/commerce/shopper-baskets/v1/organizations/{orgId}/baskets) requires a POST to create a basket and returns a basket ID that must be stored in App State. Add a basketId App State variable (String) and set it when the user first adds an item to the basket. All subsequent basket operations (add item, update quantity, apply promo, retrieve) require this basket ID as a path segment. Test the full session flow: open the app, browse products, add to basket, close and reopen the app after 30+ minutes, and verify the token refresh happens transparently and the basket persists. SCAPI guest baskets may not persist across sessions without a registered shopper token — test this behavior on your specific SFCC org configuration and decide whether to require login before basket creation.
Pro tip: Log token expiry events to Firestore during development so you can see exactly when tokens expire and how often refresh is triggered. Remove this logging before going to production to avoid leaking token metadata.
Expected result: After simulating a 401 error (by manually expiring the token), the app transparently refreshes the token and retries the failed SCAPI call without showing an error to the user.
Common use cases
Branded mobile storefront for a retail enterprise
A global fashion retailer replaces their existing mobile app with a FlutterFlow-built storefront powered by SFCC. Guest shoppers browse the product catalog, use the SCAPI search API for keyword and category filtering, and add items to a basket — all managed through FlutterFlow's native UI with the retailer's custom brand design. The Cloud Function handles SLAS guest token minting on app launch.
A mobile storefront with a home screen featuring a hero banner, featured product grid, and category navigation. A product search screen with keyword input and filter chips. A product detail screen with image carousel, size selector, and Add to Basket button. A basket screen with item list and proceed to checkout button.
Copy this prompt to try it in FlutterFlow
Registered shopper account and order history app
An existing SFCC retailer builds a companion FlutterFlow app for their loyalty customers. Registered shoppers log in via the SLAS registered shopper PKCE flow (handled by the Cloud Function), access their order history from SCAPI's Shopper Orders endpoint, and manage their saved addresses and payment methods.
A customer account app with a login screen (email/password fields posting to the Cloud Function's registered token endpoint), an order history list with order status and item thumbnails, a saved addresses management screen, and a loyalty points balance widget.
Copy this prompt to try it in FlutterFlow
Field sales app for in-store associates
Retail associates use a FlutterFlow app to look up SFCC product inventory, check pricing, create customer baskets for assisted selling, and place orders on behalf of customers. The app uses SLAS client credentials flow (admin scope) via the Cloud Function, restricted to internal staff via FlutterFlow's own authentication gate before making any SCAPI calls.
An internal sales associate app with a product search bar with barcode scanner, product detail view with real-time inventory by location, a customer lookup screen, and a basket builder with the ability to apply promo codes and place orders.
Copy this prompt to try it in FlutterFlow
Troubleshooting
Cloud Function returns 401 or 400 from the SLAS authorize endpoint
Cause: The SLAS client ID is incorrect, the SLAS application is not configured with the correct redirect URI in Business Manager, or the required scopes are not granted to the SLAS client.
Solution: Verify in SFCC Business Manager under Administration → SLAS Administration → Client Registry that your client ID exists, the redirect URI matches exactly what the function uses, and all required scopes (sfcc.shopper-products.rw, sfcc.shopper-baskets-orders.rw) are granted. Also confirm your org ID and shortcode are correct — a wrong shortcode returns a network error, not a 401.
SCAPI product search returns 401 even immediately after receiving a fresh token
Cause: The SCAPI base URL shortcode or org ID is incorrect, causing the request to reach the wrong org. Alternatively, the access token scope doesn't include product search.
Solution: Double-check the SCAPI base URL in the SFCCShop API Group — it must match https://{your_shortcode}.api.commercecloud.salesforce.com exactly. Verify the orgId variable passed to the API Call matches your SFCC organization ID. Log the full token from the Cloud Function and decode it at jwt.io to verify the scope and aud fields match your SFCC org.
Basket operations fail with 401 mid-session after working initially
Cause: The shopper access token expired (typically after 30 minutes) and the refresh logic was not triggered before the basket call.
Solution: Ensure the proactive token refresh check (Step 4) runs before any basket or checkout API Call. Add a tokenExpiry comparison in the Action Flow: if (DateTime.now().millisecondsSinceEpoch / 1000) > (tokenExpiry - 300), call RefreshToken before the basket operation. For basket calls in particular, add an On Error 401 handler that refreshes and retries once.
SCAPI product detail JSON Path mapping returns null values in FlutterFlow
Cause: SCAPI product detail and product search hit have different JSON schemas. JSON Paths generated from a search response do not apply correctly to a product detail response.
Solution: Open the GetProductDetail API Call → Response & Test tab and paste an actual product detail JSON response (not a search hit). Click Generate JSON Paths again to see the correct paths for the detail schema (e.g. $.id, $.name, $.longDescription, $.imageGroups[0].images[0].link). Create a separate SFCCProductDetail Data Type with paths mapped from the detail response — do not reuse the SFCCProductHit Data Type.
Best practices
- Never place SLAS client credentials (client ID for admin flows, client secret) in FlutterFlow API Calls or Custom Actions — SLAS token minting must live entirely in the Cloud Function to prevent enterprise-level security incidents.
- Build separate FlutterFlow Data Types for SCAPI product search hits and product detail objects — they have different JSON schemas and mixing them causes null field errors in your UI.
- Implement proactive token refresh before basket and checkout operations rather than reacting to 401 errors — a mid-checkout 401 creates a poor user experience and can lose basket state.
- Store the SFCC basket ID in App State as soon as it is created and pass it to all subsequent basket operations — do not recreate the basket on every screen, as this creates orphaned baskets in SFCC.
- Use SCAPI over legacy OCAPI for all new FlutterFlow builds — SCAPI is the current Salesforce standard with SLAS auth, while OCAPI uses a different auth pattern and is being deprecated for shopper-facing features.
- Add the expand query parameter to SCAPI product detail calls to retrieve images, prices, and variations in a single request rather than making multiple API calls per product screen.
- Verify your SLAS token expiry configuration in SFCC Business Manager rather than assuming 30 minutes — different orgs configure different expiry windows and your refresh timing should match your actual expiry.
- Test the full session lifecycle (launch → browse → basket → simulated token expiry → refresh → checkout) on a real device before shipping, as SCAPI session behavior differs between sandbox and production SFCC environments.
Alternatives
Magento's REST API uses simpler OAuth 1.0 token-based authentication and is open-source, making it more accessible for smaller teams than SFCC's enterprise SLAS architecture.
WooCommerce offers a much simpler REST API with consumer key/secret authentication — ideal for SMB merchants who need a FlutterFlow storefront without the enterprise complexity of SFCC.
Ecwid's embeddable WebView storefront and simpler REST v3 API are significantly easier to integrate into FlutterFlow than SFCC's SLAS-based architecture, making it a better fit for non-enterprise use cases.
Frequently asked questions
Do I need a paid Salesforce Commerce Cloud contract to build this integration?
SFCC is an enterprise product sold on annual contracts with no public free tier. However, Salesforce provides sandbox environments for development that partners and customers can access. Contact your Salesforce account team or a Salesforce Commerce Cloud partner for sandbox access. There is no self-serve sign-up like there is for simpler e-commerce APIs.
Can I use SFCC OCAPI instead of SCAPI for my FlutterFlow app?
OCAPI (Open Commerce API) is the legacy Salesforce commerce API with a different authentication mechanism and endpoint structure. Salesforce is focusing development on SCAPI + SLAS for shopper-facing applications and recommends SCAPI for all new builds. If your SFCC org only has OCAPI configured, the auth pattern will differ — consult your Salesforce partner to determine which API version your org supports.
How do I handle registered shopper login (not just guest tokens)?
For registered shopper login, the SLAS flow requires collecting the user's email and password in FlutterFlow, posting them to your Cloud Function's registered-login endpoint, which runs the SLAS registered shopper PKCE exchange and returns a registered access token. The registered token unlocks order history, saved addresses, and persistent baskets. The Cloud Function code must handle both guest and registered token flows as separate endpoints. Never collect or transmit Salesforce shopper passwords anywhere except through the SLAS-authenticated Cloud Function.
Why do my SCAPI product search results look different from what I see in Business Manager?
SCAPI product search results are filtered by the site_id and may respect inventory, pricing, and catalog visibility rules configured in Business Manager for that site. If products appear in Business Manager but not in API search results, check that the products are assigned to the catalog linked to your site_id and that their online-from/online-to dates make them active. Also verify the expand parameter includes pricing to see price information in the response.
Is the SFCC + FlutterFlow architecture suitable for a high-traffic production app?
Yes, but rate limits apply. Verify the SCAPI request quota for your org in your Salesforce contract or in the SFCC Business Manager — SCAPI quotas are org-scoped. The Firebase Cloud Function layer adds latency (~50-200ms) for token operations, but product and search calls go directly from FlutterFlow to SCAPI after token acquisition. Cache token values aggressively in App State and avoid re-minting tokens on every screen load.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation