Frequently asked questions

Yes, you can create photography portfolios that automatically generate album pages based on Google Drive folders. Use the Google Drive API (REST API v3) to fetch photos from specific folders and display them as sliders or slideshows in Webstudio. You'll need to set up API authentication and create resources in Webstudio that connect to your Google Drive folders. This allows for automatic updates when you add new photos to your Drive folders.

Currently, you cannot directly use .env variables from exported apps as resource variables in the Webstudio builder. The builder and exported app environments are separate. However, this type of functionality for handling different environments (development, staging, production) with different API endpoints is being considered for future development.

Slow server response times are often caused by Resources (API calls) placed at the root level. If you're using a Resource globally but only need it on specific pages (like Airtable for a careers page), move the Resource to the body of that specific page instead of the root. Airtable is particularly slow - consider switching to Baserow for faster API responses. Server response times can drop from 1200ms to 200ms by moving Resources appropriately. Caching options for Resources are planned to help with slow APIs.

Currently, Webstudio is primarily designed for receiving data rather than sending API requests directly from the frontend. For triggering actions like sending requests to third-party services (Postmark, etc.), you would need to implement custom JavaScript in an HTML Embed component or use a webhook form that connects to a backend service like n8n or Make.com to handle the API calls.

When working with n8n workflows and Webstudio webhook forms that include file uploads, ensure your n8n workflow can handle multipart/form-data requests. Test the webhook endpoint outside of Webstudio first to verify it processes files correctly. In Webstudio, set the form action to your n8n webhook URL and method to POST. For file inputs, make sure the form has enctype='multipart/form-data'. Consider implementing error handling in your n8n workflow to provide meaningful feedback to users. Also, be aware of file size limitations both in Webstudio and your n8n hosting environment.

When integrating with Ghost CMS, the API only returns 15 items by default. To ensure all entries are included in your sitemap, add '&limit=all' to the Ghost API endpoint. This parameter will fetch all available entries instead of just the default limited set.

Slow server response times are often caused by API resources being loaded on every page, even when not needed. Solutions:

1. Move API resources from the root to specific pages where they're actually used,
2. Consider faster CMS alternatives - Airtable is notably slow while Baserow is faster,
3. Implement caching for API responses when data doesn't change frequently. Moving a slow Airtable resource from root to page-specific usage can reduce server response time from 1.2s to 200ms.

To integrate Directus CMS with Webstudio, you need to use GraphQL queries similar to other CMS integrations. First, set up your Directus API endpoint, then create GraphQL queries in Webstudio's resource panel. You can find GraphQL schema and test queries in Directus's built-in GraphQL playground. The process is similar to integrating other headless CMS platforms that support GraphQL.

When integrating Ghost CMS with Webstudio, make sure to add '&limit=all' to your API endpoint URLs. By default, Ghost's API only returns 15 items, which can result in incomplete sitemaps and missing content. Adding this parameter ensures all your Ghost content is properly included in your Webstudio site's sitemap and navigation.

For Sanity CMS dynamic pages:

1. Create a general resource for all posts using the URL field (not expression editor): https://YOUR-PROJECT.api.sanity.io/v1/data/query/production?query=*[_type == "post"]{..., person->, mainImage{asset->{url}}},
2. Create a single post resource using the expression editor: https://YOUR-PROJECT.api.sanity.io/v1/data/query/production?query=*[slug.current=="${system.params.slug}"][0]{..., person->, mainImage{asset->{url}}}. Use system.params.slug for URL parameters. Avoid multiple queries in GROQ within the URL as Webstudio may have issues with them.

When setting up headless WordPress with Webstudio, you may encounter issues where data displays in the builder but not on the published site. This is often because WordPress hosting providers (like SiteGround) block Cloudflare Workers requests, treating them as bots. Contact your hosting provider to whitelist Cloudflare Worker IP addresses. SiteGround specifically requires adding Cloudflare IPs to their whitelist.

Contentful's API response structure separates linked entries and assets into different arrays, which creates challenges with Webstudio's expression editor limitations. Since you can't easily connect linked entries and assets within the expression editor, the recommended solution is to create a data transformer using a CloudFlare Worker or similar service to restructure the API response before it reaches Webstudio.

API limits vary by platform: Airtable's free plan has very restrictive limits that can be hit quickly. Baserow has more generous limits (around 10 concurrent requests) and works well for sites with under 1000 visitors per day. For production sites, consider self-hosting Baserow for more freedom, or use dedicated blog CMS platforms like Ghost, Hyvor Blogs, or Zenblog. Always implement caching to avoid hitting limits on every page load.

The most common cause of slow server response (1+ seconds) is API resources being loaded globally at the root level when they're only needed on specific pages. Airtable is particularly slow and can cause 1.2s response times. Moving resources to page-specific usage and switching to faster alternatives like Baserow can reduce response times to 200ms. Caching options for resources are planned for future implementation (GitHub issue 4077).

Yes, Webstudio plans to add cache options for resources (GitHub issue 4077). This would allow users to override CMS/API cache headers and enable Cloudflare edge caching, which would improve performance and reduce API calls to the origin server. This is particularly useful for data that doesn't change frequently.