Integration Field advanced usage

Developing with Prismic
1

Hey! We are starting to use prismic and are trying to define features we can/want to use.

At the moment I’m looking into Integration Fields and what limitation they have.

I was able to enable the feature and push data into the prismic via n8n and I was able to use that information in my slices. This is great and I see multiple use-cases where we will use this.

Now, I’m looking into possible advanced uses of Integration Fields and for that I would need to access the whole catalogue, but I don’t seem to find that is possible.

In our testing repo, we have a prototype of a real estate agency with multiple properties managed by an external tool. Properties change state, are added/deleted multiple times a day on that external service. Via n8n we push the property list into prismic Integration Fields successfully. Now, we need to create a slice/component that lists all the available properties and links to a details page. Obviously, no editor should need to update the properties manually in prismic, it should happen automatically, specially as everything in the catalogue is up to date.

Is something like the above possible with Integration Field or should I look into connecting to the external service directly?

Thanks!

2

Hey team! Integration Fields aren’t designed to auto-update Pages when something in the catalog changes. The model works like: you manage your catalog data, and editors manually select the items they want in each Page’s UI.

When you say that you would need to access the whole catalogue, not sure what you meant there, but you can expose as many fields as you need through your custom API endpoint as long as the JSON matches the structure Integration Fields expects. For example, you can add any additional data you want inside the blob object of each item.

If you have an example of you of your product items i can show you how you could structure the payload,

3

Hi!

I didn’t test that yet, so if the editor manually selects an items and that item’s blob is updated (ex: price changes), the page would also not change?

Actually my catalogue (apart-immo--apart_immo_properties) has 52 items, one per property. The idea was to grab all the items in the catalogue, loop over them to render everything.

Thinking about this now, I could instead create a catalogue entry that has all the information I need in the blob, in my case all 52 items with only the data that I display. That would only work if an update to that entry also triggers a re-render (same as above).

4

Hi Filipe, great questions, right now you’re basically exploring Integration Fields right up to their limits, so this is super useful context.

if the editor manually selects an item and that item’s blob is updated (ex: price changes), the page would also not change?

If the editor has selected an item from an Integration Field, and later the catalog sync updates that item’s blob (for example, a new price), the next time the page is fetched from Prismic, the API will return the updated blob. The editor does not need to reselect the item.

Where things might not look “automatic” is on your frontend side, depending on how you render:

  • If you’re using SSR or client-side fetching, you’ll see the new data as soon as:

    1. Prismic re-pulls the catalog (up to every ~30 minutes), and

    2. The page is requested again.

  • If you’re using static generation, you’ll need a rebuild or some kind of revalidation/webhook for the new data to show up.

So: Integration Fields do reflect changes to the external catalog, but they don’t re-save documents or force any rebuild by themselves.

The idea was to grab all the items in the catalogue, loop over them to render everything.

This part is where Integration Fields aren’t a great fit. There’s no API in Prismic to “fetch the entire Integration Fields catalog” directly. You only get Integration Field data through documents where an editor has selected items.

For a use case like “list all available properties and link to detail pages,” you’ll be better off with connecting to the external service directly from your app (backend or frontend) to fetch the full property list and render your listing page there. Use Prismic for the page layout / content around it.

I could instead create a catalogue entry that has all the information I need in the blob, in my case all 52 items…

You could technically create a single Integration Field item whose blob holds an array of all 52 properties, but that becomes a bit of a hack and not something we recommend at all: it will involve having just a very large payload, no filtering, and still no direct way to query that catalog entry unless a document selects it.

5

@Pau thanks for your replies, they were really helpful!

I think I will do exactly as you said, continue to use Integration Fields for elements that the editor should have a hand on and keep “normal” service queries for other stuff.

1 Like