#Salesforce128 人がディスカッション中

This would be a great place to introduce yourself and start making connections in the Salesforce community. I’d keep it friendly and focused on the intersection of Salesforce, marketing, ecommerce, and business processes.

Hi everyone! 👋 I’m Angela, and I’m excited to be part of the

!

I’m located in the Wausau, Wisconsin area and have a background in digital marketing, ecommerce, and business operations. My interest in Salesforce really took off when I had the opportunity to work on the business side of a Salesforce implementation. I realized how much I enjoy connecting business needs, technology, processes, and customer experience.

I’m currently building my Salesforce skills through Trailhead, have earned Agentblazer Champion status, and am working toward the Salesforce Administrator certification.

I’m especially interested in learning more about Salesforce consulting, administration, marketing, ecommerce, and automation. I’d also love to connect with other Trailblazers and learn from your experiences!

Excited to be here! 💙

Hi Rangadas - the pattern you describe (works from Postman and Render, but Meta's real webhook to the Site never reaches @HttpPost) almost always comes down to one thing: Salesforce is returning a redirect (a 302), and Meta - unlike Postman or a Render test - does not follow redirects, so the POST body is dropped and your Apex never runs. 

Why the Site redirects, and what to check: 

1. Guest user Apex class access (the most common cause). For a public Site, the Site's guest user profile must have the Apex class explicitly enabled (Site > Public Access Settings > Enabled Apex Class Access > add your class). If it's missing, Salesforce redirects the unauthenticated request toward login (a 302), which Meta silently drops - looking exactly like 'the method didn't execute'. Postman/Render either followed that redirect or you were authenticated, which is why it seemed to work there. 

2. Prove it's a redirect. Hit the exact Site endpoint with curl -i (or Postman with 'follow redirects' turned off): curl -i -X POST

. If you see a 302 with a Location back to a login page, that's your smoking gun. 

3. Exact URL + trailing slash. Make sure Meta calls the full Site path

with no trailing-slash mismatch - Site URL rewriting can 301/302 on canonical differences. 

4. Re-verify the GET handshake against the Site itself. Meta's initial verification is a GET with hub.mode / hub.challenge / hub.verify_token that must echo hub.challenge back. If your class only has @HttpPost, or you only verified while pointed at Render, add an @HttpGet that returns the challenge and re-subscribe against the Site URL. 

5. Respond fast, process async. Meta expects a quick 200; do the heavy work in a Queueable or @future so you don't hit the timeout and trigger retries. 

My money's on #1 - grant the guest user the class and re-test with the redirect-revealing curl. Also confirm the Site is Active and 'Require Secure Connections (HTTPS)' is on. 

Hope that cracks it!

Hi @Vasu Kasula

Did you try below options- 

1. Refresh the Decision Table Used for List Price 

2. Verify the Product Discovery Pricing Procedure and Context Definition 

3. Rebuild the Product Discovery Search Index