Skip to main content

Integrating Salesforce Commerce Cloud (SFCC) Log Data

📘 Botify LogAnalyzer requires information from your web server's daily logs and your website's crawl report. This document explains how to configure Salesforce B2C Commerce (SFCC) eCDN Logpush to automatically deliver your CDN logs to integrate with Botify.

Overview

Logpush delivers batches of eCDN logs to a destination you control. You create a job via the Salesforce Commerce Cloud (SFCC) CDN Zones API, specifying:

  • Log type: http_requests

  • Log fields: The specific fields Botify needs

  • Destination path: Your S3 bucket

Prerequisites

You will need the following to set up the integration:

  1. SFCC CDN Zones API access and credentials

  2. Admin access to the AWS account

Setting up the integration

Complete the following steps to integrate your SFCC log data with your Botify project.

👀 The steps outlined here summarize actions in a third-party application. If you have questions about Steps 1 - 5, refer to the SFCC eCDN Logpush documentation.

1: Create your S3 bucket

Create a standard S3 bucket via the AWS Console, or ask your IT team for one.

2: Set the bucket policy

Add this policy to S3 > Bucket > Permissions > Bucket Policy. Replace example-bucket with your bucket name:

{
"Id": "PutObjPolicy",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowObjectFromeCDNLogpush",
"Action": ["s3:PutObject"],
"Effect": "Allow",
"Resource": "arn:aws:s3:::example-bucket/*",
"Principal": {
"AWS": ["arn:aws:iam::391854517948:user/cloudflare-logpush"]
}
}
]
}

Do not change the Principal value; it is the IAM user for the eCDN's Logpush service.

💡 To avoid orphaned partial uploads and extra storage costs, add an AbortIncompleteMultipartUpload lifecycle rule to the bucket.

3: Verify bucket ownership

Before SFCC can push logs, you must prove you own the bucket by requesting an ownership challenge token and having SFCC write it to the destination path.

curl "https://{shortCode}.api.commercecloud.salesforce.com/cdn/zones/v1/organizations/{orgId}/zones/{zoneId}/logpush/ownership" \
--request POST \
--header "Authorization: Bearer <access_token>" \
--header "Content-Type: application/json" \
--data-raw '{ "destinationPath": "s3://example-bucket/log?region=us-east-1" }'

The response includes a fileName — SFCC writes an ownership challenge file to that path in your bucket.

💡 Use {DATE} in the path (e.g., s3://example-bucket/logs/{DATE}) to auto-split logs into daily folders (YYYYMMDD).

4: Create the Logpush job

curl --location "https://{shortCode}.api.commercecloud.salesforce.com/cdn/zones/v1/organizations/{orgId}/zones/{zoneId}/logpush/jobs" \
--request POST \
--header "Authorization: Bearer <access_token>" \
--header "Content-Type: application/json" \
--data-raw '{
"name": "ExampleLogPushJob",
"destinationPath": "s3://example-bucket/log?region=us-east-1",
"logType": "http_requests",
"ownershipChallengeToken": "<token from step 3>",
"logFields": [
"ClientIP", "ClientRequestPath", "ClientRequestHost", "ClientRequestUserAgent",
"EdgeResponseStatus", "ClientRequestReferer", "EdgeStartTimestamp"
]
}'

5: Enable the job

New Logpush jobs are disabled by default. Enable it to start receiving logs:

curl "https://{shortCode}.api.commercecloud.salesforce.com/cdn/zones/v1/organizations/{orgId}/zones/{zoneId}/logpush/jobs/{jobId}" \
--request PUT \
--header "Authorization: Bearer <access_token>" \
--header "Content-Type: application/json" \
--data-raw '{ "enabled": true }'

6: Grant Botify access to your bucket

Provide your Account manager with the credentials to access your S3 bucket. We need the following information:

  • Your S3 bucket name

  • The region

  • A pair of keys

👉 We can also manage authentication via IAM or STS if you prefer.

Good to know

  • No retroactive delivery: If a job is disabled or fails temporarily, missed logs cannot be recovered.

  • No delivery frequency control: SFCC pushes logs in batches as soon as they become available. You cannot change the delivery frequency.

  • S3 ownership file: If this is missing, double-check the bucket policy because it is the most common cause.


See also:

Did this answer your question?