Integrar o Brandfolder com o Salesforce Commerce Cloud é fazer com que as imagens, os vídeos e os documentos aprovados no DAM cheguem ao catálogo da loja sem cópias manuais. Não existe um conector de comércio da Brandfolder para esta plataforma: a ligação constrói-se sobre a API pública da Brandfolder e as APIs do Salesforce B2C Commerce, com uma camada intermédia que traduz e controla os dados.
Para uma marca com catálogo, a diferença sente-se todos os dias: uma imagem antiga que continua na ficha do produto, uma versão sem aprovação que vai para a loja, uma equipa de marketing que corrige o ficheiro no DAM e a loja que nunca fica a saber. Na Avafa tratamos este tipo de projetos na nossa área de integração de DAM com ecommerce, e este guia resume o que decidir antes de começar.
Neste artigo vê o que a documentação oficial permite, que dados vão em cada sentido, como se faz a integração em passos, que riscos aparecem e uma lista de verificação para validar antes de ir para produção.
Existe um conector oficial entre Brandfolder e Salesforce Commerce Cloud?
Não encontrámos um. Segundo a página de integrações da Brandfolder, consultada em outubro de 2026, o único conector de comércio listado é o do Shopify. Aparecem também Salesforce (para equipas de vendas), Salesforce Marketing Cloud, Sitecore, Drupal, WordPress e Contentful, mas nenhum para o B2C Commerce.
A mesma página indica que a Brandfolder tem uma API pública para aplicações à medida e que plataformas como o Zapier e o Tray.ai permitem construir integrações próprias. Para o Salesforce Commerce Cloud, o caminho realista é por isso a API, com desenvolvimento à medida ou com uma plataforma de integração.
Convém não confundir os dois produtos da Salesforce. O conector do Marketing Cloud serve para criar comunicações com ativos do DAM e não alimenta o catálogo da loja.
O que o Salesforce Commerce Cloud permite fazer do lado da loja
O B2C Commerce guarda as imagens do produto por tipo de vista, e é esse conceito que dita como o DAM deve ser organizado. Segundo a documentação da API de scripts do Salesforce, o método de imagens do produto recebe o nome da vista, devolve as imagens ordenadas por índice e, numa variante sem imagens desse tipo, recorre à primeira imagem do produto mestre.
Na prática, isto obriga a decidir no DAM quais os ativos que são imagem grande, miniatura ou vista de detalhe, e em que ordem. Se essa informação não existir, a integração carrega ficheiros mas a loja não sabe onde os pôr.
Do lado das APIs, a documentação do Salesforce indica que a Open Commerce API (OCAPI) está descontinuada e que, em projetos novos ou em grandes reformulações, se deve usar a B2C Commerce API (SCAPI) como API REST por defeito. Quem desenha uma integração agora deve partir daí e confirmar com a equipa técnica quais os recursos de catálogo disponíveis para escrita.
O que a API da Brandfolder oferece
A API v4 da Brandfolder é uma API REST com autenticação por token no cabeçalho de autorização. Segundo a documentação oficial, a hierarquia é: organização, Brandfolder, secção e coleção, ativo e anexo. O anexo é o ficheiro propriamente dito; o ativo é o registo que o agrupa.
Os ativos podem ser listados por Brandfolder, por secção, por coleção ou por etiqueta, e a listagem de uma secção aceita incluir os anexos na mesma chamada. Os campos personalizados são pares chave-valor associados a um único ativo, e tanto as chaves como os valores são sempre texto. É neles que se guarda o SKU, o tipo de vista ou o mercado de destino.
Para saber o que mudou sem consultar tudo de cada vez, a Brandfolder oferece webhooks com os eventos de criação, atualização e eliminação de ativos. O aviso é leve: traz o identificador do ativo e o tipo de evento, mas não os dados. Por isso o seu serviço tem de ir buscar o ativo à API depois de receber o aviso.
Que dados vão em cada sentido
A regra de base é uma só fonte de verdade para cada dado. O DAM manda nos ficheiros e no estado de aprovação; o Salesforce Commerce Cloud manda no produto, no catálogo e no que aparece em cada site.
| Dado | Sistema mestre | Sentido |
|---|---|---|
| Ficheiro e versão atual | Brandfolder | DAM para loja |
| Estado de aprovação | Brandfolder | DAM para loja |
| SKU e associação ao produto | Campo personalizado | DAM para loja |
| Tipo de vista e ordem | Campo personalizado | DAM para loja |
| Produto e catálogo | Commerce Cloud | Só na loja |
| URL final da imagem | Commerce Cloud | Loja para registo |
Este quadro é o elemento mais importante do projeto. Quando dois sistemas podem alterar o mesmo campo, aparecem os conflitos que mais tempo consomem a resolver.
Como integrar passo a passo
O desenho funciona melhor em fases curtas, validadas com um conjunto pequeno de produtos antes de se alargar ao catálogo.
- Definir no Brandfolder as chaves de campos personalizados: SKU, tipo de vista, ordem e mercado.
- Decidir como se mapeia cada tipo de vista do DAM para os tipos de vista do catálogo da loja.
- Criar o acesso à API da Brandfolder com um utilizador técnico que só veja os Brandfolders necessários.
- Criar o cliente de API no Salesforce com as permissões mínimas para ler e escrever no catálogo.
- Construir o serviço intermédio: recebe o webhook, consulta o ativo, valida os campos e envia para a loja.
- Testar com 20 a 50 produtos, incluindo variantes, e comparar o resultado com o que o catálogo mostra.
- Ativar a sincronização por lotes para o catálogo completo e deixar o webhook para as alterações diárias.
O serviço intermédio pode correr no seu próprio alojamento ou numa plataforma de integração. O importante é que guarde um registo de cada ativo processado e do resultado.
Como funcionam os webhooks na prática
Os avisos podem chegar fora de ordem e podem repetir-se, por isso o serviço deve ser idempotente. A documentação da Brandfolder diz que se deve usar a hora do evento para ordenar as mensagens, e que um ativo novo gera primeiro um evento de criação e depois um de atualização, quando fica pronto para uso.
O endereço de retorno tem de ser público e responder de imediato com um código 2xx. Se não responder, a Brandfolder tenta de novo até 15 vezes, com esperas crescentes, e uma subscrição que falhe de forma persistente é desativada. Também é desativada, em cerca de 30 minutos, se a chave de API perder o acesso ao recurso.
A conclusão prática: o serviço responde logo, põe o aviso numa fila e processa depois. Quem processa dentro do pedido arrisca-se a perder avisos quando o catálogo for grande.
Riscos mais comuns e como os evitar
Os problemas repetem-se de projeto em projeto, e quase todos nascem de falta de regras e não de falta de tecnologia.
| Risco | Como se evita |
|---|---|
| Ativo sem SKU no DAM | Campo obrigatório antes de aprovar |
| Imagem antiga na loja | Comparação periódica DAM contra loja |
| Ativo retirado ainda visível | Tratar o evento de eliminação |
| Avisos perdidos | Fila e reconciliação diária |
| Variante sem imagem | Regra de recurso ao produto mestre |
O segundo risco merece atenção. O webhook diz que algo mudou, mas só uma comparação regular confirma que a loja ficou igual ao DAM. Recomendamos uma reconciliação diária que liste os ativos aprovados e verifique o que a loja mostra.
Lista de verificação antes de ir para produção
Esta lista resume o que revemos em cada projeto de ligação entre um DAM e uma loja.
- Cada ativo aprovado tem SKU, tipo de vista e ordem preenchidos.
- Existe um mapa escrito entre os tipos de vista do DAM e os da loja.
- A chave de API da Brandfolder pertence a um utilizador técnico com acesso limitado.
- O cliente de API do Salesforce só tem as permissões necessárias.
- O serviço responde ao webhook de imediato e processa por fila.
- O mesmo aviso, recebido duas vezes, não duplica imagens.
- As variantes sem imagem própria mostram a do produto mestre.
- Há uma reconciliação diária e alguém que recebe os erros.
- Está escrito o que acontece se a Brandfolder ou a loja estiverem indisponíveis.
- Existe um plano para repor o estado anterior se a carga falhar.
Como trabalhamos na Avafa
Começamos por mapear os campos do DAM e os tipos de vista da loja, e só depois escolhemos a forma de ligação. Revemos o fluxo e as permissões antes de qualquer desenvolvimento, para que o projeto não arranque com dois sistemas a mandar no mesmo dado. Se quiser ver como abordamos estes projetos, comece pela página de integração de DAM com ecommerce.
Guias relacionados do mesmo cluster
Se a plataforma ainda não está decidida, estes guias analisam outros DAM e outras lojas:
- Widen com Salesforce Commerce Cloud
- OpenText DAM com Salesforce Commerce Cloud
- Canto com Salesforce Commerce Cloud
- Brandfolder com BigCommerce
- Brandfolder com SAP Commerce Cloud
- Agência de SEO para Salesforce Commerce Cloud
Perguntas frequentes
A Brandfolder tem conector nativo para o Salesforce Commerce Cloud?
Não consta da página oficial de integrações da Brandfolder, que lista apenas o Shopify como conector de comércio. A ligação faz-se pela API da Brandfolder e pelas APIs do Salesforce.
Que API devo usar do lado do Salesforce?
A documentação do Salesforce indica que a OCAPI está descontinuada e que a SCAPI é a API REST por defeito em projetos novos. Confirme com a equipa técnica os recursos de catálogo disponíveis.
Os webhooks da Brandfolder trazem os dados do ativo?
Não. O aviso identifica o ativo e o tipo de evento, e o serviço tem de consultar a API para obter os dados. Pode chegar fora de ordem, por isso use a hora do evento.
Onde guardo o SKU de cada imagem?
Num campo personalizado do ativo. A documentação indica que cada campo é um par chave-valor de texto associado a um único ativo.
Quanto tempo demora um projeto destes?
Depende do número de ativos, de sites e de regras. Um piloto com poucas dezenas de produtos permite medir o esforço real antes de se comprometer com o catálogo completo.