Integrating Duda into a SaaS platform (3/3)
BY Jason Hummel • August 22, 2024
0 minute read

In earlier portions of this series, we laid out a roadmap for programmatically generating simple websites and enabling your SaaS platform's users to edit those sites in a completely white-labeled environment. We also touched on the ability to push information stored in your application to a website as content. 


This overview of Duda’s capabilities centered around simple bits of data like phone numbers, email addresses, business hours, etc. While that business-level information is obviously important for any website, SaaS products often contain more complex data structures that need to be exposed to the public. This is the subject we’ll cover now in this third and final blog post of our series. 


Collections


In Duda, complex data structures can be integrated via collections. A collection consists of a list of similar objects (e.g. staff members, products, events, news items, etc.). Each object in the list consists of a group of the same properties. For staff members, this might be something like a name, bio, profile picture. For events it could be a date, time, description and a URL to buy tickets. 


In contrast to the business-level data we talked about in previous posts, collection data can be pulled into Duda from a public data source rather than pushed via a Duda API endpoint. Duda can check for changes in collections automatically and update the live website to ensure the content remains in sync.


Collection data can be connected to widgets in the same way we connected our business-level data. However, because collection data is a list of items instead of a single piece of discrete data, only certain widgets are capable of displaying that data on a page. These types of widgets include the list widget, the photo gallery widget and the accordion widget, among others. 


Once a collection has been connected, you'll be able to connect the individual properties of the items to display within the widget's layout.



Dynamic pages


Along with widgets, collections can also be connected to dynamic pages. With dynamic pages, Duda can generate an entire page per item in a collection. Examples may include a staff directory or a product catalog. Dynamic pages can make creating dozens or even hundreds of pages a snap. These pages will stay synced with the collection data, so updating or deleting an item in the collection will update or delete its respective page.


Working with collections in a template


If you recall, in the first part of this series we connected the widgets in a template to placeholder data stored in the content library. By providing placeholder data, we were able to see some content to aid in making design decisions. When a new site based on the template was created, we were able to easily update the data stored in the content library. Any connected widgets would then display the new information via the connections. 


When planning a SaaS integration, we want to do something similar with collections. Within the template, we will specify a URL to placeholder data. We can use this placeholder to hook up our widgets and design dynamic pages. At the time of site creation, we will update the collection endpoint to point to real user data. As long as the collection consists of the same property names as the placeholder collection, all the widgets and dynamic pages connected to the collection will update as well.


To create a new collection in a template, select content in the left menu. Select collections, then click the New Collection button. You'll be presented with the option to select the type of collection you want created. Duda has the option to create an internal collection, where the data is managed right within the editor, or an external collection, where data is managed from an outside source.



For our purposes, we want to connect straight to data from a SaaS platform. So our collection should be connected to an “External Database”. Remember, we are connecting to a database only in concept. Duda will not make calls directly through a database connection. The actual data needs to be made available through a public URL. 


Before we can proceed with creating the collection, we need to talk about the data format. We're going to need a URL of data to which we will connect. The template design phase is a good time to get a designer and developer together to talk about what information in the SaaS product should be made available on the website. The output of this meeting should be a static JSON file the developer can reference and the designer can use as placeholder data within the template. The important thing is that the eventual real customer data will match the schema of the placeholder JSON. 


For illustration purposes, let's use a fictional SaaS platform for musicians. One of the data types collected in our product is upcoming tour information for artists. Let’s say our hypothetical SaaS company gets a designer and developer together for a meeting to begin planning the Duda integration and they come up with the following JSON structure.


Sample JSON


With an agreed upon data structure, we can return to our template and finish creating our collection. Back in the editor we've navigated to the new collection screen. Here we are going to choose the “External Database” option to hook a collection up to the JSON file we've agreed upon. The file should be uploaded to a web server, or you can use something like Amazon's S3 service. Anywhere you can grab a URL and see the JSON output should work. (Note: This URL must return data with a Content-Type header value of “application/json”, other content types will result in an error when creating the collection.)



On the new collection screen, enter the URL of your JSON file in the “Endpoint URL” field. You'll also be able to expand an option to define the actual path to the data inside the endpoint. If we go back and reference our JSON, we'll see the list of performances is actually inside a “performances” property, which is in turn inside a “tour” property. In this case, we would enter “tour.performances”, as the path to our items.


Once we've configured our endpoint, we can click the “Fetch Collection” button to confirm everything is working properly. If Duda is able to find a collection, the first item in the list will be displayed as a preview. Be sure to confirm the data looks correct before continuing.


Below the preview, you'll see an option to choose which property in your collection you'd like to use as a page item URL. Whatever property you choose will be used in the URL of dynamic pages. In our tour example, we could choose the “id” property to generate paths similar to “/tour/1”, “tour/2”, etc. (we'll cover how we configure the “tour” part of the URL a bit later).



The next screen allows us to choose the data type for each property in our collection. This configuration step tells the Duda editor which properties are able to connect to which widgets. For instance, configuring the “address” property in the collection to be a data type of “location”, will make this property available when connecting a performance to a map widget. Update each property in the collection to the correct data type, and click “done”. 


Congratulations! We've just configured our first collection.



Working with dynamic pages in a template



Now that we've imported some data, let's look at how we can create some new pages based on the information. By tying our collection to dynamic pages, we’ll ensure the information on the website is always in sync with the information in the SaaS platform. We won't have to ever worry about website visitors receiving out-of-date details. 


Creating a dynamic page is similar to creating a static page on a Duda website. Select “pages” and then click “new page” to see the new page modal. This modal presents some commonly used layouts ready to be populated by data.



After adding a dynamic page, the editor will place you in “dynamic mode”. This means that any changes you make to this page will be reflected across all the other dynamic pages. You are free to make design adjustments just like on any other Duda page. You can also connect data to any of the widgets on the page using the same steps we used to connect business data. If you select a property from a collection, however, the value will change for each page generated by the collection. This allows us to create multiple pages with the same design, but different content.



Providing navigation to dynamic pages


Linking to your new pages can be done either by connecting to a collection-compatible widget, such as the list widget, or by providing links right in your navigation. Simply navigate back to the “pages” tab and click on the gear icon next to your dynamic page. The flyout menu has an option to hide or show the pages in the navigation. We'll give you the option to add the dynamic pages as a sub-navigation to an existing page. By default, the page will be hidden from your navigation on all devices—but you can change that at any time.


Updating the collection with live data


Now that the template is updated to include dynamic pages. We can turn our attention back to the website creation flow. As a review here's the list of steps from the previous articles.


  • Create a website from a template
  • Update the content library with business data
  • Create a user account
  • Grant access to the website


While the designer was hard at work on creating the template, our developer has hopefully had time to surface the data at a public URL. Assuming everything is ready to go, we're going to add one additional call to the list to update the collection endpoint to point to live data. Each website will have a URL that provides data on a single account in your product. The format is up to you. It could be via path parameters such as /client/1/collection_name. You could also use a query parameter to filter the items as in /collection_name?client=1. It just has to be available over a standard GET request.

API call

 
curl --request PUT \ 
--url https://api.duda.co/api/sites/multiscreen/{site_name}/collection/{current_collection_name}
 \ 
--header 'authorization: Basic123abc=' \ 
--header 'content-type: application/json' \ 
--data '{
  "external_details": {
      "enabled": true,
      "external_endpoint":"https://example.org/artists/1/tour",
      "page_item_url_field": "id",
      "collection_data_json_path": "tour.performances"
  },
  "name":"Performances"
}'


Note: Updating a collection with a new endpoint. You should always provide values for any existing property, even if the new value is equal to the existing value. Failure to send values for properties such as page_item_url_field, collection_data_json_path, etc. will result in the erasure of the existing value.



Putting it all together


We now have all the pieces to instantly create a beautiful and useful website. While it's a lot of steps to write out, in practice, you only need to implement a handful of API calls. It's also easy for different tracks of your implementation to be worked on simultaneously. Your designer can work on templates while a developer gets to work surfacing the data for your collections. Another designer or developer could be working on your white-labeling. And finally, someone could be assigned to implement the UI and API calls within the SaaS application itself. By parallelizing the work, an implementation can come together very quickly.



Here's a full list of the steps, broken into separate work tracks:



This series provides a standard roadmap to creating fully functional websites programmatically through your SaaS application, but there is room for customization. Do you want sites published immediately or do you want your users to customize them first? Are you going to charge users before they access the editor, or do you want a try-before-you-buy experience where the transaction doesn't take place until the user tries to publish the site? Do you have interactive features you'd like to come pre-configured on the new sites via a custom widget? There is a lot to think about, but luckily, Duda can provide you with dedicated account management to help you through each step and decision. 


Need a little help? Duda also has a number of experts available to help design and build your templates. And there are several software development agencies like RapidDev that can help you integrate Duda.


If you are interested in providing websites through your SaaS platform, contact our team today!


Jason

Jason Hummel

Director of Solution Engineering, Duda

With over 25 years of web development experience, Jason is focused on providing elegant, usable solutions that follow current industry standards.

Did you find this article interesting?


Thanks for the feedback!

Core web vitals: What agencies need to know in 2026

By Shawn Davis • April 1, 2026
Core Web Vitals aren't new, Google introduced them in 2020 and made them a ranking factor in 2021. But the questions keep coming, because the metrics keep changing and the stakes keep rising. Reddit's SEO communities were still debating their impact as recently as January 2026, and for good reason: most agencies still don't have a clear, repeatable way to measure, diagnose, and fix them for clients. This guide cuts through the noise. Here's what Core Web Vitals actually measure, what good scores look like today, and how to improve them—without needing a dedicated performance engineer on every project. What Core Web Vitals measure Google evaluates three user experience signals to determine whether a page feels fast, stable, and responsive: Largest Contentful Paint (LCP) measures how long it takes for the biggest visible element on a page — usually a hero image or headline — to load. Google considers anything under 2.5 seconds good. Above 4 seconds is poor. Interaction to Next Paint (INP) replaced First Input Delay (FID) in March 2024. Where FID measures the delay before a user's first click is registered, INP tracks the full responsiveness of every interaction across the page session. A good INP score is under 200 milliseconds. Cumulative Layout Shift (CLS) measures visual stability — how much page elements unexpectedly move while content loads. A score below 0.1 is good. Higher scores signal that images, ads, or embeds are pushing content around after load, which frustrates users and tanks conversions. These three metrics are a subset of Google's broader Page Experience signals, which also include HTTPS, safe browsing, and mobile usability. Core Web Vitals are the ones you can most directly control and improve. Why your clients' scores may still be poor Core Web Vitals scores vary dramatically by platform, hosting, and how a site was built. Some of the most common culprits agencies encounter: Heavy above-the-fold content . A homepage with an autoplay video, a full-width image slider, and a chat widget loading simultaneously will fail LCP every time. The browser has to resolve all of those resources before it can paint the largest element. Unstable image dimensions . When an image loads without defined width and height attributes, the browser doesn't reserve space for it. It renders the surrounding text, then jumps it down when the image appears. That jump is CLS. Third-party scripts blocking the main thread . Analytics pixels, ad tags, and live chat tools run on the browser's main thread. When they stack up, every click and tap has to wait in line — driving INP scores up. A single slow third-party script can push an otherwise clean site into "needs improvement" territory. Too many web fonts . Each font family and weight is a separate network request. A page loading four font files before rendering any text will fail LCP, especially on mobile connections. Unoptimized images . JPEGs and PNGs served at full resolution, without compression or modern formats like WebP or AVIF, add unnecessary weight to every page load. How to measure them accurately There are two types of Core Web Vitals data you should be looking at for every client: Lab data comes from tools like Google PageSpeed Insights, Lighthouse, and WebPageTest. It simulates page loads in controlled conditions. Lab data is useful for diagnosing specific issues and testing fixes before you deploy them. Field data (also called Real User Monitoring, or RUM) comes from actual users visiting the site. Google collects this through the Chrome User Experience Report (CrUX) and surfaces it in Search Console and PageSpeed Insights. Field data is what Google actually uses as a ranking signal — and it often looks worse than lab data because it reflects real-world device and connection variability. If your client's site has enough traffic, you'll see field data in Search Console under Core Web Vitals. This is your baseline. Lab data helps you understand why the scores are what they are. For clients with low traffic who don't have enough field data to appear in CrUX, you'll be working primarily with lab scores. Set that expectation early so clients understand that improvements may not immediately show up in Search Console. Practical fixes that move the needle Fix LCP: get the hero image loading first The single most effective LCP improvement is adding fetchpriority="high" to the hero image tag. This tells the browser to prioritize that resource over everything else. If you're using a background CSS image for the hero, switch it to anelement — background images aren't discoverable by the browser's preload scanner. Also check whether your hosting serves images through a CDN with caching. Edge delivery dramatically reduces the time-to-first-byte, which feeds directly into LCP. Fix CLS: define dimensions for every media element Every image, video, and ad slot on the page needs explicit width and height attributes in the HTML. If you're using responsive CSS, you can still define the aspect ratio with aspect-ratio in CSS while leaving the actual size fluid. The key is giving the browser enough information to reserve space before the asset loads. Avoid inserting content above existing content after page load. This is common with cookie banners, sticky headers that change height, and dynamically loaded ad units. If you need to show these, anchor them to fixed positions so they don't push content around. Fix INP: reduce what's competing for the main thread Audit third-party scripts and defer or remove anything that isn't essential. Tools like WebPageTest's waterfall view or Chrome DevTools Performance panel show you exactly which scripts are blocking the main thread and for how long. Load chat widgets, analytics, and ad tags asynchronously and after the page's critical path has resolved. For most clients, moving non-essential scripts to load after the DOMContentLoaded event is a meaningful INP improvement with no visible impact on the user experience. For websites with heavy JavaScript — particularly those built on frameworks with large client-side bundles — consider breaking up long tasks into smaller chunks using the browser's Scheduler API or simply splitting components so the main thread isn't locked for more than 50 milliseconds at a stretch. What platforms handle automatically One of the practical advantages of building on a platform optimized for performance is that many of these fixes are applied by default. Duda, for example, automatically serves WebP images, lazy loads below-the-fold content, minifies CSS, and uses efficient cache policies for static assets. As of May 2025, 82% of sites built on Duda pass all three Core Web Vitals metrics — the highest recorded pass rate among major website platforms. That baseline matters when you're managing dozens or hundreds of client sites. It means you're starting each project close to or at a passing score, rather than diagnosing and patching a broken foundation. How much do Core Web Vitals actually affect rankings? Honestly, they're a tiebreaker — not a primary signal. Google has been clear that content quality and relevance still dominate ranking decisions. A well-optimized site with thin, irrelevant content won't outrank a content-rich competitor just because its CLS is 0.05. What Core Web Vitals do affect is the user experience that supports those rankings. Pages with poor LCP scores have measurably higher bounce rates. Sites with high CLS lose users mid-session. Those behavioral signals — time on page, return visits, conversions — are things search engines can observe and incorporate. The practical argument for fixing Core Web Vitals isn't just "because Google said so." It's that faster, more stable pages convert better. Every second of LCP improvement can reduce bounce rates by 15–20% depending on the industry and device mix. For client sites that monetize through leads or eCommerce, that's a revenue argument, not just an SEO argument. A repeatable process for agencies Audit every new site before launch. Run PageSpeed Insights and record LCP, INP, and CLS scores for both mobile and desktop. Flag anything in the "needs improvement" or "poor" range before the client sees the live site. Check Search Console monthly for existing clients. The Core Web Vitals report surfaces issues as they appear in field data. Catching a regression early — before it compounds — is significantly easier than explaining a traffic drop after the fact. Document what you've improved. Clients rarely see Core Web Vitals scores on their own. A monthly one-page performance summary showing before/after scores builds credibility and makes your technical work visible. Prioritize mobile. Google uses mobile-first indexing, and field data shows that mobile CWV scores are almost always worse than desktop. If you only have time to optimize one version, do mobile first. Core Web Vitals aren't a one-time fix. Platforms change, new scripts get added, campaigns bring in new widgets. Build the audit into your workflow and treat it like any other ongoing deliverable, and you'll stay ahead of the issues before they affect your clients' rankings. Duda's platform is built with Core Web Vitals performance in mind. Explore how it handles image optimization, script management, and site speed automatically — so your team spends less time debugging and more time building.

Why systems, not tools, are the future of vertical SaaS

By Ilana Brudo • March 31, 2026
Vertical SaaS must transition from tools to an AI-powered Vertical Operating System (vOS). Learn to leverage context, end tech sprawl, and maximize retention.

Maximizing SaaS growth with an API-driven website builder

By Shawn Davis • March 27, 2026
Automate client management, instant site generation, and data synchronization with an API-driven website builder to create a scalable growth engine for your SaaS platform.
Show More

Latest posts