Catalog API with an sk_live key

Connect a catalogue API with an sk_live key

When to use the Catalog API

The Fynd Catalog API is useful when product data is held in a system that can serve it directly rather than publishing an XML or CSV feed. An API connection is a good fit for custom storefronts, headless commerce stacks, PIM systems, ERP integrations, or internal catalogue services. It lets your integration send structured product knowledge to Fynd using authenticated requests.

Use the Catalog API for catalogue facts such as identifiers, titles, descriptions, prices, availability, product URLs, images, brands, categories, and variant information. Use custom knowledge FAQs for durable questions that are not individual product records, such as shipping guidance or store policy explanations. Use a sitemap crawl for public editorial pages where BlogPosting or Article JSON-LD should be discovered.

The API must be called with a live secret key in a Bearer authorization header. A key with the sk_live prefix is a secret credential. Treat it like a password: it can authorize changes to your live catalogue connection.

Create and store the secret safely

Create the live secret in the Fynd settings area intended for API keys. Copy the key only into a secure secret manager, deployment secret, or encrypted environment variable. Do not paste it into a public issue, a frontend bundle, a product feed, a browser-based script, or a repository.

Store it with a name that makes its purpose clear:

FYND_CATALOG_API_KEY=sk_live_replace_with_your_secret

The sk_live prefix identifies a live secret; it is not a placeholder to send by itself. Use the complete key generated for your workspace. If a key is exposed, revoke or rotate it immediately in Fynd, update the stored secret, and deploy the replacement. Do not rely on deleting a log line after a secret has appeared there.

Restrict access to the secret to the service or deployment environment that performs catalogue synchronization. A browser should never receive it. Any user who can inspect client-side JavaScript or network requests must not be able to recover your live key.

Authenticate requests

Send the key in the standard HTTP Authorization header using the Bearer scheme:

curl -X POST "https://api.fynd.example/catalog" \
  -H "Authorization: Bearer $FYND_CATALOG_API_KEY" \
  -H "Content-Type: application/json" \
  -d @catalog-payload.json

Use the actual endpoint and request shape supplied by your Fynd API documentation or integration configuration. The example demonstrates the authentication pattern, not a substitute for the endpoint contract. The critical part is:

Authorization: Bearer sk_live_...

Do not use a query parameter such as ?api_key=. Query strings often appear in access logs, analytics tooling, proxies, and browser history. The Authorization header is designed for credentials, although you should still make sure request logging masks it.

Always use HTTPS. Never send an sk_live key to an HTTP endpoint. Verify that redirects do not forward credentials to a different host. Your HTTP client should fail safely on unexpected redirects or certificate errors.

Design a dependable catalogue payload

Give every product a stable unique identifier. A SKU or permanent product ID is usually appropriate. Stable IDs allow an update to replace the correct record instead of producing duplicates. A product title and description should be customer-readable and factual. Include product URLs so answers can point users to the current storefront page.

A conceptual record may contain fields like:

{
  "id": "SKU-100",
  "title": "Travel mug",
  "description": "Insulated stainless-steel mug with a leak-resistant lid.",
  "price": 24.95,
  "currency": "EUR",
  "availability": "in_stock",
  "url": "https://example.com/products/travel-mug",
  "brand": "Example",
  "categories": ["Drinkware", "Travel"]
}

Follow the exact schema expected by the endpoint. Do not assume every field in this illustration is mandatory or that the field names are universal. Validate the payload in a non-production workflow where available, then send a small real sample before uploading a complete catalogue.

Avoid marketing-only descriptions, internal supplier notes, and data unrelated to customer questions. Accurate materials, dimensions, compatibility, care instructions, and availability are much more helpful than broad claims. Normalize currencies, stock values, URLs, and category values so that the same information does not arrive in several conflicting formats.

Build the synchronization process

Run synchronization from a trusted server-side job, worker, CI environment, or integration service. Read the sk_live key from the environment at runtime. Never hard-code it in source code. Make the process idempotent where the API supports it: retrying the same run should update the intended products rather than duplicating them.

Use manageable batches if your catalogue is large. Record the product IDs in each batch, the response status, and a non-sensitive error summary. Do not log the Authorization header, the full key, or complete customer data. Add retries only for transient errors, such as timeouts or temporary service responses, and use backoff to avoid repeatedly sending the same failed request.

Synchronize after customer-facing catalogue changes: publishing products, changing price or availability, replacing descriptions, correcting compatibility data, or discontinuing items. Set the schedule based on how quickly those changes need to become available in Fynd.

Before a full update, test a small batch that includes a normal product, an out-of-stock product, a product with variants, and a product with a long description. Confirm the imported records in Fynd match the source system. This catches mapping errors before they affect the whole catalogue.

Verify results in Fynd

After a run, inspect the Catalog API source in the knowledge or sync UI. Check accepted records, rejected records, and any errors. Search for the sample identifiers you sent and compare their titles, prices, URLs, and availability with your source system.

If the integration also uses a sitemap source, remember that the sync UI can show blog counts for sitemap content. Those counts come from crawled pages detected as BlogPosting or Article and classified as page_type=blog; they are not catalogue API records. Keep source responsibilities clear when investigating an answer.

Use a monitoring alert for repeated authentication failures, unexpected record-count drops, or batches with persistent validation errors. The first indication of a rotated or incorrectly deployed key is often a 401 or 403 response. Treat it as a credential or permission problem, not a reason to retry indefinitely.

Troubleshooting

Authentication fails

Confirm that the complete current sk_live key is loaded by the server-side process and sent as Authorization: Bearer <key>. Check for whitespace, an outdated deployment secret, key revocation, or a key copied from the wrong workspace. Do not paste the key into logs while debugging.

Requests are accepted but products are wrong

Inspect the mapping from your source fields to the API schema. Verify stable IDs, price units, currency, availability values, and canonical URLs. Test a single product and compare it field by field.

Duplicate products appear

Make sure retries preserve the same identifier and that the upstream system does not generate a new ID on every export. Check whether multiple jobs or environments are sending the same catalogue as different sources.

A batch fails partway through

Record which identifiers succeeded, correct the invalid records, and retry only the failed portion if supported. Do not blindly resend an unknown batch without checking whether the API operation is idempotent.

Security checklist

• Keep sk_live only in server-side secrets.
• Send it only in an HTTPS Bearer header.
• Mask authorization values in logs and monitoring.
• Rotate immediately if exposure is suspected.
• Use least-privilege access around the deployment secret.
• Review integration jobs after key rotation.

Summary

The Catalog API gives custom systems a direct route into Fynd product knowledge. Authenticate server-side requests with Authorization: Bearer sk_live_..., use stable identifiers and clean product data, validate small batches first, and protect the live secret throughout its lifecycle.