Docs

Catalog sync

Scan a resource and replace stored response documents.

Choose your scope

Read only the resources your key can access. Keep the credential on your server, and assess storage and redistribution rights in the data license before building a local copy.

Walk the pages

Follow pagination for the resource and view you store. The example requests pages of 100 Core documents.

javascript
const url = new URL('https://api.golfapi.dev/drivers');
url.searchParams.set('limit', '100');
 
while (true) {
  const response = await fetch(url, {
    headers: { Authorization: `Bearer ${process.env.GOLFDEV_API_KEY}` }
  });
  if (!response.ok) throw new Error(`GolfAPI.dev: ${response.status}`);
  const { data, page } = await response.json();
  // Store each Core document by its stable club id.
  await saveClubs(data);
  if (!page.has_more) break;
  url.searchParams.set('cursor', page.next);
}

saveClubs is your application’s storage function. The example stops on errors; handle rate limits and retries as described in handling responses.

Store documents

Upsert by club id, preserve variant IDs, and retain updated_at. Store the response version with your snapshot. Replace an unprojected document rather than merging it blindly: a field that is now absent should not keep an old value.

Use Catalog to interpret publication gaps. A removed record does not establish that the product is discontinued.

Refresh the catalog

Repeat the scan for the resource and view you store. Compare updated_at within that document to identify changes. The API does not currently provide an updated_after filter or a change feed.

A cursor identifies a pagination position, not a permanent checkpoint. On a cursor 400, restart the scan with the original filters. Keep stored documents and caches separate across views, test and live data, and keys with different access.

Continue with queries and pagination and handling responses.