How do I get tour dates to show up on my website automatically

Get tour dates on the website automatically by treating the page as a reader of one write surface — usually Bandsintown, Songkick Tourbox, or Dice — then either embedding that vendor’s widget or syncing the same feed into owned JSON / a CMS, often with n8n. The designer ships the module once. The manager never opens Designer to change a city. Hard-coded date strings in the layout are not automation; they are a brochure that lies after the first routing change. This spoke sits under Websites That Feel Like Films. The ops rule — one calendar, many readers — is the companion post tour dates without five logins. This one is the site install.

On builds for acts like Foxtide and Arkayla, the tour block is a job: next dates, a ticket or notify path, an off-season empty state. I do not attach invented sell-out counts or “X% more ticket clicks” to those sites. The receipt is the architecture: one write, one display contract, no Designer in the Tuesday loop.

The short answer

• Pick one write surface. Everyone on the team updates that system only.
• Make the website a reader: vendor embed, owned JSON/CMS, or an n8n copy of that feed. Never all three as write paths.
• Pin numeric IDs (id_… on Bandsintown, Tourbox snippet from your Integrations page, Dice partner filters). Name match is a collision.
• Homepage: next three from the same feed as /tour. Empty state is designed. Past dates stay off the fold.
• I will not invent a ticket lift. Measure time-to-update and outbound clicks on your domain.

Reader on the site	Write stays in	Automatic if
Vendor embed	BIT, Tourbox, or Dice	Snippet uses pinned IDs
Owned JSON / CMS	That CMS, or the vendor via sync — never both by hand	Manager never opens Designer
n8n copy	Still the vendor	Job upserts externalId and publishes

What does automatically mean on the website?

Automatically means a manager edit upstream appears on the live site without a designer deploy. It does not mean five widgets, a JSON file, and a spreadsheet all claiming to be current.

What fans see	What actually happened	Honest?
New city on /tour after a Tourbox save	Widget or API reader	Yes
Homepage “next 3” reshuffles when a room sells out	Same feed, status field flipped	Yes
Designer pastes a new date into a rich-text block	Manual publish	No
n8n writes CMS and the intern types a second row	Two write surfaces	No
Link-in-bio still has last month’s rooms	Third calendar	No

The same class of failure shows up on trades sites: hours and the phone number must match Google Business Profile, not a hero line someone forgot to edit. That is the trades and SMB playbook in a different costume. Tour dates are the artist version of hours. If they live in the design file, they will be wrong in public.

Test it out loud:

1. Who adds a date at 11:40 p.m. the night a hold confirms?
2. Do they open Bandsintown, Tourbox, Dice, or the CMS — one tool?
3. After they save, can /tour move without you?

If step 3 is “I have to ship a build,” you do not have automatic dates. You have a launch brochure.

How fast the reader can move depends on the host. None of these are vendor SLAs. They are install choices.

Host	What “automatic” requires after an upstream save	Typical lag if you get it right
Vendor widget (BIT / Songkick / Dice)	Fan hard-refresh; widget fetches vendor JSON	Seconds to a few minutes
Webflow CMS via API	PATCH then publish items	Minutes — unpublished staged items look live in Editor and dead on .webflow.io production
Static HTML on a CDN	Client fetch with a short cache, or n8n writes JSON and a rebuild hook	Minutes if TTL is minutes; a day if you cached the HTML
Link-in-bio tools	Point at /tour	Never, if someone is still typing cities there

• Widget pages are not behind a “cache HTML for 24h” rule during announce week
• Webflow tour items are published, not only staged
• Static hosts either fetch in the browser or rebuild on the sync
• You have a named test: add a date, refresh, see it, delete it

Embed, owned JSON, or n8n — which reader should the site use?

Three honest site patterns. Pick one reader. The write surface is a separate choice (covered in the five-logins spoke). Mixing readers is fine only when they share the same upstream ID. Mixing writers is how you get two tours.

Reader	Best when	Manager still writes in	Site risk
Vendor embed (BIT / Songkick / Dice)	You need it live this week; type system can absorb the widget	That vendor	Iframe/CSS fight; logo; past-dates default
Owned JSON or CMS collection	Film-grade rows, waitlist fields, per-show URLs	CMS or the vendor if you sync — not both by hand	Dual-write if Editor stays unlocked
n8n sync into CMS/JSON	You already have a CMS contract and a real API	Still the vendor	Failed jobs, unpublished Webflow items, stale cache

Decision order (stop at the first yes):

1. Will the manager live in Bandsintown, Tourbox, or Dice this quarter? → embed that widget first.
2. Does the iframe break the type system or hide sold-out/waitlist states you need? → pull the API into your row component.
3. Does the host not fetch JSON in the browser (or do you need CMS fields widgets cannot hold)? → n8n copies the feed into the CMS. Managers stay out of those fields.

Host	Typical reader that stays automatic	Usually a trap
Webflow	BIT/Songkick/Dice embed, or CMS collection the API can publish	Dates in a rich-text embed on the Home canvas
Framer / custom React	Embed, or client fetch of BIT JSON with id_ + app_id	Code override that hard-codes an array of shows
Astro / other static	Client fetch, or n8n → JSON + rebuild hook	Checking a markdown file into git for every city
WordPress	Official widget or a thin wrapper around it	A page builder “event” block typed by hand

Embed is the default. Custom JSON is the upgrade when design or fields demand it. n8n is plumbing for that upgrade, not a personality.

How do Bandsintown, Songkick, and Dice embeds actually work?

Each embed is a live read of that vendor’s listing. Edits in the vendor dashboard update the snippet. You still have to paste the right snippet once, with the right identity, and not cache it into a fossil.

Vendor	Official path (checked September 2026)	What the site gets	Limit to budget for
Bandsintown	Widget builder + customization table	Script from widgetv3.bandsintown.com + .bit-widget-initializer	Past dates default on; display-limit default is show all
Songkick	Tourbox → Integrations → Your website	Iframe fed by Tourbox	Parent CSS cannot restyle iframe guts; attribution stays
Dice	Event Listing Creator	Partner widget (list or gallery); optional purchase overlay	Partner ID + API key; no partner login, no official widget

Bandsintown attributes I actually set on artist homepages:

Attribute	Use on the site	Default to override
data-artist-name	id_{artist_id} from the public /a/{id} URL	Name string — collisions
data-display-limit	3 on the homepage	Show all
data-display-past-dates	false on Upcoming modules	true
data-display-start-time	true when doors vs show time matters	false
data-display-logo	Off when the type system cannot absorb it	On

BIT’s setup help is blunt: if the widget flakes, swap the artist name for the numeric ID. Two BIT widgets on one page is a blank hole and a support ticket that blames “Bandsintown being down.”

Songkick Tourbox is copy-paste from your Integrations page. Sold-out on the website widget is a Tourbox control, not a CSS trick. Festival “pick day” on the widget does not rewrite every other Songkick reader — do not assume /tour and Bandcamp saw the same Tuesday.

Dice is the third embed, not a vibe. The partner widget creator asks for an 8-digit Partner ID (attribution of clicks, views, purchases) and a 40-digit API string. Filter by exact artist / venue / promoter values. Script loads from Dice’s widget host (widgets.dice.fm on the WordPress wrappers). Dice’s Ticket Holders GraphQL is a partner API with restricted fields and a MIO token — not the default artist-site path. If you do not have a Dice partner account, you do not have this embed. Link out to the Dice event URL instead of inventing a scraper.

Same-day embed installs (one vendor, not three):

Bandsintown

1. Claim the artist in Bandsintown for Artists. Copy the numeric ID from the public /a/{id} URL.
2. Build the widget. Script: https://widgetv3.bandsintown.com/main.min.js. Initializer class: bit-widget-initializer.
3. Set data-artist-name="id_{id}", homepage data-display-limit="3", data-display-past-dates="false".
4. Paste once on Home and once on /tour (tour page omits the limit). Do not leave an old widget.bandsintown.com script beside v3.

Songkick

1. Tourbox → Integrations → Your website.
2. Copy that artist’s snippet. Paste into an HTML embed on Home (limit if the widget UI offers one) and /tour.
3. Mark sold-out in Tourbox when the room is gone. Do not CSS-hide the Buy button on your side while Tourbox still says on sale.

Dice

1. Open the Event Listing Creator. Pick list or gallery.
2. Enter Partner ID and API string from the partner dashboard. Filter with exact artist (or promoter) values — a venue filter on an artist site dumps the room’s whole calendar onto your fold.
3. Paste the embed. Optional purchase overlay only if Dice is actually selling that room.
4. Confirm a known live Dice event appears, then a room that is not yours does not.

You sell tickets on	Embed on the site	Do not also
Bandsintown / mixed partners	BIT widget or BIT API	A second Songkick widget you never update
Songkick-first (Bandcamp matters)	Tourbox widget	A BIT widget pointed at a duplicate profile
Dice-first rooms	Dice listing widget	A handmade “Buy on Dice” row with a stale slug

One embed matching the write surface. Two logos is not twice as automatic.

How do I pin identity so the widget is mine?

Wrong dates on an otherwise correct layout are almost always identity, not “the API is slow.”

Surface	Pin	Failure if you skip it
Bandsintown widget	data-artist-name="id_123456"	The other act with your spelling
Bandsintown API	https://rest.bandsintown.com/artists/id_{{artist_id}}/events/?app_id=...	Name lookup returns the wrong catalog
Songkick widget	Snippet from this artist’s Tourbox	Leftover intern paste
Dice widget	Partner filters for this artist / promoter, not a venue you once played	The room’s whole calendar on your homepage
CMS / n8n	Store externalId = vendor event id	Duplicate rows when the title string changes

Ship checklist:

• Public BIT URL and Tourbox URL both resolve to this act
• Widget / API uses id_ form, not a display name
• Dice filters are exact strings the partner UI accepts (their own example is a venue name like “The Underworld”)
• No second unclaimed BIT or Songkick profile for the same spelling
• Embed snippet in the repo or CMS is commented with the production ID
• Link-in-bio points at /tour, not a third handwritten list

Unclaimed duplicate profiles are how a well-meaning intern “fixes” a missing date by creating a second artist. Fans then see two calendars. Claim, merge, or report the duplicate. Do not start a new one.

When does owned JSON or a CMS beat the iframe?

Use owned JSON or a Tour CMS collection when the iframe cannot hold the job: waitlist, VIP copy, film-grade rows, or per-show URLs. The collection is still a reader if n8n or a human-in-CMS-only local calendar is the write. It becomes a second calendar the moment a manager types dates in Webflow and in Bandsintown.

Cap the schema. If the Editor can invent a new homepage from a tour row, you built a page builder and called it a calendar.

Field	Required	Why
externalId	Yes if synced	Idempotent upsert; never key on city+date alone
start (datetime, offset explicit)	Yes	Sort, “next 3”, schema
city	Yes	Homepage can render before venue locks
venue	No (TBA allowed)	Empty is not the string "TBA" unless you store TBA
ticketUrl	No	Empty drives Notify / waitlist, not a dead Buy
status	Yes	tba / presale / onsale / soldout / canceled
note	No	Support slot, festival day, door time — one line

Editor vs Designer:

Seat	May edit	Must not
Named manager	Vendor dashboard (source of truth)	Webflow Designer, Framer canvas
CMS Editor (CMS-as-truth only)	Tour collection fields above	Layout, CMS schema, new components
n8n	Mapped fields from the API	A Slack-typed override field “just this once”
Designer / studio	Row component, empty state, cache	The date string

Bandsintown’s events API returns date/time, venue, ticket links, lineup, and the BIT event page. Managers get an app_id under Bandsintown for Artists → Settings → General. BIT’s own help: each key is linked to a single artist unless they authorize otherwise. Site display is the intended use; do not scrape it into a third-party “tour aggregator” you do not have terms for.

Songkick’s developer API is a separate product with attribution terms. Commercial sites should use their own key. The Tourbox widget already satisfies most artist homepages without you standing up that API.

JSON on the page is not a second calendar if it is generated from the same externalId. Hand-maintained shows.json in the repo is hard-coding with extra steps.

How should n8n sync dates without becoming a second calendar?

n8n is a copier. The vendor listing stays the write surface. The workflow reads, maps, upserts, and publishes. If a manager can also type a show in the CMS, you have rebuilt five logins with extra YAML.

I have 600+ automations built and 500+ live, and I have collaborated directly with the n8n team. The tour job is boring on purpose: HTTP in, map fields, write CMS, stop. It is not an agent loop.

Reference wiring (Bandsintown → Webflow). Swap the HTTP URL if Songkick or Dice is the source and you have licensed API access.

1. Schedule Trigger. Minutes during announce week, hours in the off-season. Not days.
2. HTTP Request GET https://rest.bandsintown.com/artists/id_{id}/events/ with query app_id and date=upcoming. Use n8n’s HTTP Request node. Store app_id in credentials, not in the canvas.
3. Map. id → externalId. datetime → start. Venue city/name → city / venue. First ticket offers[].url → ticketUrl. Empty offers → status=tba or notify, not last tour’s Ticketmaster URL.
4. Upsert. Find CMS item by externalId. Create or PATCH. Webflow Data API v2 PATCH /v2/collections/{id}/items is capped at 100 items per call.
5. Publish. Staged PATCH is not the live site. POST /v2/collections/{id}/items/publish with itemIds, or PATCH the /items/live route if you mean to skip review. Scope cms:write.
6. Reconcile. IDs present in CMS upcoming but missing from the API: mark canceled or unpublish. Do not delete the collection on an HTTP 500.
7. Fail closed. On error, leave last good rows, alert the named owner. Turn on HTTP Request retry. Do not “clear all dates” as a cleanup step.

BIT’s events date query (from their API docs): upcoming (default), past, all, or a range like 2015-05-05,2017-05-05. Homepage and /tour should request upcoming. Do not pull all onto an Upcoming module.

BIT / CMS field	Maps to	Rule
id	externalId	Unique; upsert key
datetime	start	Keep the offset; do not strip to a date-only string
venue.city	city	Required even when venue is TBA
venue.name	venue	Empty or TBA — do not invent
offers[0].url	ticketUrl	First real offer; never a fallback from last tour
offers empty	status notify/tba	No Buy
Missing from upcoming payload	unpublish or canceled	After a successful GET only

Webflow rate-limit responses tell you to respect X-RateLimit-Remaining. Batch PATCH is 100 items. A 12-date run does not need heroics. A 90-date festival summer might. If you get 429, wait and retry — do not wipe the collection to “start clean.”

n8n mistake	What fans see	Fix
PATCH staged, never publish	Site frozen; Designer looks “fine” in Editor	Publish items or use live endpoints
Key on City — May 12	Duplicate when venue locks	externalId
Treat empty upcoming array as error	Homepage hole in the off-season	Empty state module
Manager CMS edits after sync	Two tours	Lock those fields or CMS-as-truth only, never both
Cache HTML for a day	Sold-out still says Buy	Short TTL on the tour route during announce week

Client-side fetch (no n8n) is valid on hosts that can call BIT in the browser. The app_id will be public; that is how BIT’s own widget works. Still pin id_. Still cache in minutes, not days. n8n earns its keep when you need Webflow CMS fields, private keys you do not want on the page, or a rebuild hook for a fully static host.

Do not invent a webhook BIT does not document. Poll the events endpoint. If a vendor later ships a real webhook, subscribe — do not assume it exists because n8n has a Webhook node.

How do homepage and /tour share one feed?

Homepage job: prove there is a tour and get the click. Tour page job: full list plus sold-out / waitlist. Same source. Different slice.

Surface	Shows	CTA	Reader setting
Homepage	Next 3 upcoming	Tickets / Notify + All dates	BIT data-display-limit="3"; CMS sort start asc, limit 3
/tour	Full upcoming	Tickets, waitlist, notify	No limit; past dates off or in an archive
EPK	Next few + link to /tour	Booking contact, not fan ticket UX	Same feed, different chrome
Off-season	Zero rows	Email / listen — not a broken iframe	Designed empty state

BIT’s customization docs: a “Show all dates” link appears when you exceed data-display-limit. On a film-grade homepage that link should go to your /tour, not to Bandsintown.com as the primary CTA. If the widget cannot retarget that link, use the API/CMS slice instead of fighting the iframe.

Procedure for a CMS homepage:

1. Query upcoming where status is not canceled, start >= now, sort asc.
2. Render three rows: date (with offset), city, venue or TBA, status, CTA.
3. Fourth control is “All dates” → /tour.
4. Zero rows: “No shows announced — join the list,” with email capture. Not a 404-looking widget.

Timezone: store the local offset on start. “7pm” without a zone is how a West Coast graphic and an East Coast module disagree by three hours. Google’s event structured data wants offsets on startDate if you emit Event JSON-LD at all. Most artist homepages should skip rich-result chasing until they have per-show URLs. A correct widget on /tour still beats decorated JSON-LD that says Friday is on sale.

If you do emit Event JSON-LD, generate it from the same feed as the page. Do not type it in the template.

Listing status	eventStatus if you emit schema	offers.availability
On sale	EventScheduled	InStock only if the ticket URL is live
Sold out	EventScheduled	SoldOut
Canceled	EventCancelled	Omit a live Buy
Postponed	EventPostponed	No leftover Friday URL
TBA venue	Skip schema or omit location.name until real	Do not invent a venue so Google is happy

Google’s own note: a schedule index is not the event page. If you will not ship /tour/city-date leaves, skip the rich-result chase. Widget on /tour is enough for the fan job.

What should the module do when there is no ticket URL?

Missing offers is a state. It is not a reason to paste last tour’s URL. TBA venue is a state. Sold out is a state. The module maps states to buttons. The manager flips them on the source.

Signal	Button on the site	Do not
Ticket / offer URL present	Buy / Tickets (that URL)	Wrap it in a generic “Learn more”
BIT offers empty	Notify Me (trigger=notify_me per BIT’s API CTA guidance) or your email form	Last year’s Ticketmaster link
status=soldout	Waitlist / sold out label	Hide the row so fans think the tour skipped their city
status=canceled	Remove from upcoming or label canceled	Leave EventScheduled JSON-LD
Venue TBA	City + date + TBA; no Buy	Invent a room “for the graphic”
Dice overlay enabled	Purchase in the widget if that is the partner setup	A second Buy that hits a different slug

BIT API CTA table I actually implement when we render rows:

API signal	Site control
Ticket offer URL	Buy
No offer	Notify
Always optional	RSVP — only if you want BIT’s list
Artist follow	Track — only if you want BIT’s list, not yours

Dice purchase overlay is a partner-widget option (“let fans buy tickets directly through the widget”). It is not a license to show Buy on rooms that are not on sale. If Dice is not the ticketer for a support slot, do not embed a Dice Buy for a bill you do not control.

Checklist before you ship CTAs:

• Empty ticketUrl cannot render Buy
• Sold-out flips in the source and on /tour without a designer
• TBA has no ticket href
• Canceled is gone from “Upcoming” or explicitly labeled
• Social creatives pull city/date from the listing, not from a Figma frame that froze on Tuesday

What usually breaks first when teams try this?

The first break is almost never “Bandsintown went down.” It is identity, cache, or a second write surface.

Symptom	First check	Not the first check
Site stale, vendor dashboard correct	CDN / HTML cache / Webflow unpublished items	“The API is down”
Widget blank	Artist ID vs name; leftover v1 script + v3 script	Redesign the Tour page
Wrong act’s rooms	Name match	New CMS collection
Two rows for one night	TBA event left in place after the venue locked	A new n8n workflow
n8n “succeeded,” site unchanged	Staged items never published	Rebuild the whole site
Sold-out on Instagram, Buy on the fold	Status not on the source; hard-coded URL in the component	A/B test the button color

Hard-code audit (run it on any artist site you inherit):

• View source or the CMS. Are dates in a collection / widget, or in a rich-text block?
• Change one listing upstream. Does /tour move without a designer?
• Sold-out a room in BIT/Tourbox/Dice. Did the CTA change?
• Is there an off-season empty state, or a 2024 date still labeled Upcoming?
• Does the homepage cap at three from the same ID as /tour?

If any box fails, you do not have automatic tour dates. You have a brochure with a tour section.

Cost of the brochure, without fake percentages: support DMs, a canceled room that still looks on sale, a manager waiting on a designer during announce week, and Google/social previews that still show last Friday’s city. I have shipped hundreds of production sites. The tour module that survives is the one a tired manager can update from a phone.

Handoff is the slow failure. Intern created the BIT account on a personal Gmail. Label “has access.” Nobody can reset it in announce week.

Seat	May do	Must not
Named owner (one human)	Create, edit, cancel, change ticket URLs	Share the password in a group chat
Backup (one human)	Same, only if owner is offline	Invent a second artist profile
Designer / studio	Embed, style, cache, empty state	Type dates into the design file
n8n	Copy mapped fields	Invent a show the vendor does not have

How does this affect conversion?

A live, honest date list with a working next action is table stakes. It is not a published ticket-conversion study. I will not invent a lift for this post. Measure on your domain.

The fold job is still identity first, then one listen / tour / contact path — cinema on the hero, ops on the dates. Automatic dates help conversion only by not lying and by not hiding the ticket path behind a designer bottleneck.

Signal	How to measure	What it is not
Time-to-update	Edit upstream → hard-refresh /tour (minutes, not “sometime”)	A vendor SLA you can quote without their docs
Ticket clickout	GA4 outbound click on ticketUrl / widget	“X% more tickets sold”
Notify / waitlist	Form completes on sold-out or TBA rows	A fake Buy that 200s
Empty-state captures	Email confirms in the off-season	A blank iframe you call “minimal”
Mismatch rate	Screenshot vendor vs site once per announce week	A Lighthouse score

If you need a number for a deck, use your clickouts after the module is honest. Do not borrow a percentage from a widget vendor’s marketing page and stitch it to a client name.

Conversion also dies when the widget fights the brand so hard fans bounce before the row renders. That is a design constraint, not a reason to hard-code. Pull JSON. Keep the feed.

Announce-week measurement (no invented lifts):

1. Monday: save one new date upstream. Hard-refresh /tour. Record minutes-to-appear.
2. Tuesday: click the ticket CTA in a private window. Confirm it is this room’s URL.
3. Wednesday: mark a room sold out upstream. Confirm Buy is gone on the site.
4. Thursday: screenshot vendor vs site. File any extra row as an identity bug, not a “sync delay.”
5. Friday: check the homepage still shows three, not the full run.

If step 1 is hours because HTML is cached, fix cache before you touch design. If step 3 fails, the CTA is hard-coded. That is the conversion bug. Button color is not.

What should I ask a designer about this?

If the designer cannot answer these in the kickoff, they are styling a brochure.

Question	Acceptable answer	Walk-away answer
Where does the date string live after launch?	Widget, API, or CMS collection	“In the hero”
Who changes a city without you?	Named manager in BIT/Tourbox/Dice	“We’ll hop on a call”
What is the empty state?	Designed module + email	“The widget handles it” (it will hole)
Homepage vs /tour	Limit 3 vs full list, same ID	Two different paste jobs
Sold-out / TBA / no offer	Mapped buttons	One Buy component
Cache	Minutes in announce week	“CDN default”
Identity	id_ / Tourbox snippet / Dice partner filter in the repo	Artist name as a string
Schema	Optional JSON-LD from the same feed, or none	Hand-typed Event markup

Designer deliverables I actually sign:

• Production artist IDs in the brand doc
• Homepage module + /tour using the same reader
• Empty, TBA, sold-out, canceled, on-sale states in the component
• No date literals in Figma exports that ship to production
• A 15-minute manager test in staging: add a fake date upstream, watch it appear, delete it

Cinema on the fold is a different job. Dates are ops wearing the type system.

When is a custom site worth it for this?

A custom (or heavily code-component) site is worth it for tour dates when the reader must match a film-grade system the iframe cannot, or when you need fields and URLs the widgets will not give you. It is not worth it so a designer can type cities faster. They will not.

Worth custom	Not worth custom
Row component that matches the world; API or CMS feed	A $ template tour section you still paste into
Waitlist, VIP, or door-time fields widgets omit	Recreating BIT’s default list in Webflow symbols by hand
Per-show URLs for Event schema you will maintain	JSON-LD on a 40-date index page
Dice/BIT/Songkick identity already pinned, design is the remaining fight	Rebuilding the write surface as a Notion database
Static host that needs n8n → JSON + rebuild	n8n because someone said “automation” in a sales call

If the manager will not open Bandsintown, Tourbox, or Dice, a custom site will not save you. They still need a write surface. Custom only changes how pretty the reader is.

Quiet local calendars (four basement shows, no Bandcamp/Spotify need) can be CMS-as-truth. Say that out loud. The moment platforms matter, the vendor listing is the write and the CMS is the reader — see the five-logins post.

What should I skip if I only have a week?

A week is enough to ship an honest reader. It is not enough to stand up n8n, Event rich results, and a waitlist product.

Do this:

1. Name the write surface (BIT, Tourbox, or Dice) and the human who owns the login.
2. Paste one official widget with pinned ID. Homepage display-limit 3; /tour full list; past dates off.
3. Design the empty state.
4. Point link-in-bio at /tour.
5. Hard-refresh test: add a date upstream, confirm the site, remove it.

One-week calendar that actually ships:

Day	Do	Do not
Mon	Name owner + write surface; claim the profile	Debate n8n vs Make
Tue	Paste one official widget with pinned ID	Embed BIT and Songkick “just in case”
Wed	Homepage limit 3; /tour full; past dates off	Style the iframe until 2 a.m.
Thu	Empty state + bio link to /tour	Footer tour list in Webflow rich text
Fri	Upstream add / sold-out / delete test	Event JSON-LD, Dice GraphQL, waitlist product

Skip until the widget is boring and correct:

• n8n / Webflow Data API
• Client-side BIT JSON (unless the iframe is already a brand fail)
• Google Event rich results
• Dual BIT + Songkick embeds
• Dice GraphQL
• A second “tour” section in the footer
• Per-show marketing pages

When it is not worth doing yet: you have no named owner, no claimed vendor profile, and two people still updating Instagram first. Fix the write surface. Then install the reader. Automatic on a site that nobody updates upstream is a very pretty empty state.

FAQ

How do I get tour dates to show up on my website automatically?

Treat the site as a reader of one write surface. Embed the Bandsintown, Songkick Tourbox, or Dice widget that matches that surface, or pull the same feed into owned JSON / a CMS (n8n if the host needs a sync job). Do not type dates into the design file. Pin numeric IDs so the widget is yours.

How do I measure whether automatic tour dates on my website are working?

Time how long a source edit takes to appear on /tour after a hard refresh, and track outbound ticket or notify clicks on your domain. Screenshot the vendor dashboard against the site once per announce week. I will not invent a ticket-sales percentage; if the CTA still says Buy after you mark sold out upstream, the reader is broken.

What usually fails first when teams try this?

Identity, cache, or a second write surface. The widget matches the wrong artist, HTML is cached for a day, Webflow items stay staged, or someone types a parallel list in the CMS. Check artist ID, publish state, and “who is allowed to type a date” before you file a vendor outage.

How long does this take to show results?

A pinned official embed can be live the same day you claim the profile: paste, limit the homepage, design the empty state, test an upstream edit. n8n plus CMS publish is extra days because staged items and reconciliation are easy to get wrong. Spotify and Bandcamp have their own clocks; those are platform readers, not this module.

What should I skip if I only have a week?

Skip n8n, Event schema, and a second embed. Ship one official widget with pinned ID, homepage next-three, /tour as the full list, and an empty state. Point the bio link at /tour. Custom JSON waits until the iframe is the actual problem.

When is this not worth doing yet?

When nobody owns the vendor login and Instagram is still the write surface. Automatic display cannot fix a calendar that is not written down in one place. Claim the profile, name the owner, then install the reader. A custom tour UI on top of that chaos just fails in better type.

CTA

One write surface. The site reads it. No Designer in announce week.

Explore /websites or book a Website sprint at /contact?intent=websites-sprint.