When an entry has been created in SCHMA Studio but does not appear on your live website or application, the cause is usually a missing publication step, a mismatched content type slug, an incorrect workspace header, or frontend framework caching.

Step 1: Check entry publication status

SCHMA's Delivery API strictly excludes draft content to prevent unfinished work from leaking to production visitors. Open the entry in Studio and inspect its status badge in the header bar. If the badge displays Draft or Modified, click Publish to promote the entry to the published index.

Step 2: Verify the content type slug

Queries made via REST, GraphQL, or SDK require the content type's permanent API slug, which often differs from its human display name. For example, a content model labeled 'Case Study' may have the slug case_study or case-study. Verify the exact slug under Content Models in the Studio.

Step 3: Check API key scope and tenant slug

Confirm that your request includes the two mandatory HTTP headers:

• x-tenant-slug: Must match the exact slug of the workspace containing the entry. If querying from environment variables, ensure SCHMA_TENANT_SLUG is set correctly.
• Authorization: Must be a valid token formatted as Bearer <token>. Ensure the key was created with the delivery or read permission scope.

Step 4: Isolate with a direct cURL request

To quickly verify whether the issue lies in your frontend code or in the API response, execute a direct HTTP request from your terminal:

curl "https://api.schma.dev/v1/delivery/entries?type=your_content_type_slug&limit=5" \
  -H "Authorization: Bearer your_api_key_here" \
  -H "x-tenant-slug: your_workspace_slug_here"

If this command returns your entry in the JSON payload, SCHMA's API is functioning correctly, and the issue is caused by frontend caching or build-time data fetching.

Step 5: Check frontend caching and Next.js ISR

Modern frontend frameworks heavily cache data responses. If you are using Next.js App Router, fetch requests without explicit revalidation settings may be aggressively cached at build time:

// Ensure fetch specifies an ISR revalidation window or disables caching
const res = await fetch("https://api.schma.dev/v1/delivery/entries?type=post", {
  headers: {
    Authorization: `Bearer ${process.env.SCHMA_API_KEY}`,
    "x-tenant-slug": process.env.SCHMA_TENANT_SLUG!,
  },
  next: { revalidate: 60 }, // Revalidate every 60 seconds
});