Pick One Source of Truth for Tour Dates — Then Let Everything Else Read It

Keep tour dates current by picking one place as the write surface — usually Bandsintown for Artists or Songkick Tourbox — then letting your website, Bandcamp, and streaming surfaces read from that listing. The failure is not “forgetting an embed.” It is five logins with five slightly different calendars, so fans see a canceled room on the site and a still-onsale link on Bandcamp. This spoke sits under Websites That Feel Like Films.

The short answer

• Choose one source of truth. Everyone on the team updates that system only.
• Website: embed the widget or pull the API — do not hard-code dates in the design file.
• Bandcamp reads Songkick; wrong shows usually mean a name collision — pin your Songkick Artist ID.
• Spotify surfaces concerts from ticketing partners (including Bandsintown among others); it is a read surface, not your ops spreadsheet.
• TBA, presale, and sold-out are status fields on the source — not separate sticky notes in Slack.

What’s the right source of truth?

Pick the platform your manager will actually open on a Tuesday. Then make every other surface a reader.

Source of truth	Best when	Website pattern	Downstream readers
Bandsintown for Artists	You want a site widget + API control, RSVPs, and Spotify partner path	Official widget or events API	Site, Spotify (via partner feed when eligible), Bandsintown surfaces
Songkick Tourbox	Bandcamp sync and Songkick’s website widget matter most	Tourbox website widget	Site, Bandcamp (via Songkick ID), other Tourbox integrations
CMS collection (Webflow, etc.)	Dates are few, design must be fully custom, manager lives in the CMS	CMS → homepage “next 3” + Tour page	Site only — you still update BIT/Songkick for platforms

Rule: the website is almost never the only write surface if you also care about Bandcamp and Spotify. Either BIT or Songkick owns the calendar; the site displays it. CMS-as-truth works for quiet local calendars — not for a tour that must stay aligned across platforms.

On builds for acts like Foxtide, Arkayla, and Friday Pilots Club, the tour surface is a job: next dates, tickets, waitlist — not a designer-updated text block.

How do Spotify and Bandcamp fit?

They are readers, with different pipes. As of mid-2026:

Bandcamp pulls upcoming shows from Songkick. Enable “display upcoming shows” on the Bandcamp profile. If Songkick matches your artist by name alone, a same-named act elsewhere can inject phantom dates (Bandcamp’s own help jokes about surprise Tonga shows). Fix: paste your Songkick Artist ID or artist URL into Bandcamp’s Upcoming Shows settings so only your Tourbox listings sync.

Spotify does not ask you to type dates into Spotify for Artists as the primary workflow. Concerts appear when listed through Spotify’s ticketing partners. Spotify’s Live Events guidance currently points artists to partner ticketers and, when your ticketer is not a partner, to upload via Bandsintown so listings can generate on Spotify. Partner sets change; treat Spotify as a distribution surface and verify your team’s current path in Spotify for Artists / your BIT or Songkick docs when a tour announces.

Platform	Write?	Typical feed	Ops implication
Your website	No (prefer embed/API)	BIT widget/API or Songkick Tourbox widget	One embed, auto-updates
Bandcamp	No	Songkick	Claim Songkick ID; edit in Tourbox
Spotify	No	Partner ticketing feeds (BIT among paths)	List correctly upstream; allow sync time
Link-in-bio	Rarely	Manual or smart link	Point to /tour or ticket URL — don’t maintain a third calendar

If you update Bandcamp by hoping name-match magic works, you do not have a system. You have a coin flip.

Should you embed Bandsintown or Songkick?

Embed the widget that matches your source of truth. Do not embed both and update neither.

Choice	Use when	Notes (verified mid-2026)
Bandsintown widget	BIT is source of truth	Customize colors/fonts; data-display-limit, event show/hide attributes, country filters exist in current widget docs
Bandsintown API	You need a fully branded list inside your design system	Events endpoint via artist app_id; managers still edit in BIT
Songkick Tourbox widget	Songkick is source of truth	Integrations → Your website → paste code; edits in Tourbox update the site
Neither (CMS only)	Tiny calendar, no platform sync needed	Accept that Bandcamp/Spotify will not follow unless you also maintain BIT/Songkick

For film-grade artist sites, API or carefully styled widget beats a default iframe that fights your type system — but a styled widget still beats hard-coded dates that go stale the week after launch. Pair the tour module with the conversion paths in Artist Website Conversion.

Homepage: next three dates automatically

Homepage job: prove there is a tour and get the click. Tour page job: full list + sold-out/waitlist states.

Recommended pattern:

1. Source of truth holds all shows.
2. Homepage embed or API call with a display limit of 3 (BIT’s widget supports a display limit attribute; CMS queries sort by date ascending and slice three).
3. “All dates” links to /tour (or your Tour route).
4. Empty state is designed: “No shows announced — join the list” with email capture, not a broken widget hole.

Surface	Shows	CTA
Homepage	Next 3	Tickets / RSVP + All dates
Tour page	Full upcoming	Tickets, waitlist, notify
Past dates	Optional archive	Merch / listen, not dead ticket links

Managers should never open Webflow Designer to change a date string. If they must, the architecture failed.

Sold-out, waitlists, and presales

These are states on the event, not separate marketing projects.

State	What fans need	Ops move
On sale	Ticket URL	Ticket link on the source listing
Presale	Code path + window	Presale link/code in listing + email/SMS from your list; BIT/Songkick both support promotion patterns — use the one tied to your source
Sold out	Honesty + waitlist	Mark sold out in Tourbox/BIT so the widget reflects it; site waitlist form (Friday Pilots Club–shaped: date list + waitlist + email)
Canceled / postponed	Stop the click	Update or remove upstream immediately; hard-coded sites are where canceled shows keep selling embarrassment

Failure mode: Instagram says sold out, site still shows Buy Tickets because the designer pasted a Ticketmaster URL into a rich text field six weeks ago. Source-of-truth status would have flipped the CTA for free.

How to handle TBA venues

Announce the city and date when the hold is real; keep venue as TBA in the source until the contract is signed.

Practical rules:

• Use the platform’s TBA / TBD venue fields when available — do not invent a venue name “for the graphic”
• Homepage can show “City — Date — TBA” if that is what the listing holds
• Do not attach a ticket URL until the URL is live
• When the venue locks, edit the same event — do not create a duplicate listing and forget to delete the TBA

Duplicate TBA + confirmed events for the same night is how fans double-buy or miss the real link. One event record, updated in place.

What breaks when you hard-code dates in the design

Hard-coding feels faster in week one. It fails in week three.

Breakage	Cost
Stale Buy links after sellout	Support DMs, angry fans, chargebacks on the promoter side
Designer required for every add/drop	Manager waits; dates announce on social first; site looks abandoned
BIT and site diverge	SEO/social previews show the wrong next city
No empty state	Past dates linger forever under “Upcoming”
Launch day paste errors	Wrong year, wrong timezone, missing opener

If the brand needs a custom tour layout, pull structured fields (date, city, venue, ticket URL, status) from the API or a CMS that a manager can edit — still one write path. Design the row component; do not type the tour into Figma and export as text.

Manager workflow that survives tour announce week

One-page SOP for the team:

1. Announce — create/edit the show in BIT or Tourbox only.
2. Ticket — paste the final ticket URL on that listing.
3. Status — flip presale → on sale → sold out on that listing.
4. Site — verify homepage next-3 and Tour page within 15 minutes (cache/CDN: hard refresh).
5. Bandcamp — if Songkick-sourced, refresh/confirm ID once; do not re-enter dates.
6. Spotify — confirm listing appears after partner sync window (often hours to a couple of days; BIT docs have cited ~48–72 hours for BIT→Spotify in help articles — treat as approximate).
7. Social — link to your /tour or the ticket URL, not a third handwritten list.

Who owns the source of truth? Put a name in the Notion doc. Two editors without a named owner is how you get two Calendars.

CMS instead of a widget — when it is honest

Use a Tour CMS collection when:

• You need waitlist fields, VIP packages, or copy the widgets cannot hold
• Visual design must match a film-grade system with no iframe tells
• Show count is low and platforms are secondary

Still mirror critical dates into BIT or Songkick if Bandcamp/Spotify matter. CMS-only is a choice to not sync — make that choice out loud.

For editor-friendly collections, see CMS Choices Clients Will Actually Use. Cap fields: date, city, venue, ticket URL, status, optional note. No “layout mode.”

Decision list: pick your stack this week

1. Who updates dates weekly? → their tool becomes source of truth.
2. Is Bandcamp a real fan surface for you? → Songkick ID pinned, Tourbox accurate.
3. Do you need Spotify Live Events visibility? → ensure listings flow through a current Spotify ticketing partner path (often BIT if your ticketer is not already a partner).
4. Does the site need custom tour UI? → API or CMS readers; never hard-code.
5. Sold-out / waitlist required? → status on source + waitlist on site.

Integrations change (platform partnerships move). Re-verify the Bandcamp↔Songkick and Spotify partner list at the start of every major tour cycle — do not trust a setup from two albums ago.

Worked example: announce week for a 12-date run

Imagine the manager has twelve clubs, two holds still TBA, three rooms already on sale, and one soft hold that might flip Friday.

Day	Action in source of truth	What readers should show
Mon	Create 10 confirmed events with ticket URLs	Site Tour page lists 10; homepage next 3
Mon	Create 2 TBA venue events (city + date only)	Site shows City — TBA; no Buy yet
Tue	Pin Songkick ID on Bandcamp (once)	Bandcamp stops showing the other “Foxtide” in Ohio
Wed	Flip three rooms to On sale	Widget CTAs go live; social links to /tour
Thu	One room sells out → mark Sold out + open site waitlist	Buy becomes Waitlist; Instagram can match reality
Fri	TBA #1 venue locks → edit same event	Ticket link appears; no duplicate row
Sat	Soft hold dies → delete or cancel that listing	Homepage next-3 reshuffles automatically

Nobody opened Webflow Designer. Nobody retyped dates into Bandcamp. Spotify catches up on its partner sync clock. That is the product: ops, not a prettier iframe.

Multi-act and festival lineups

Festivals and multi-artist bills create duplicate and partial listings.

• Prefer the official festival event your team controls in BIT/Tourbox over every fan-wiki scrape of the same weekend.
• If Spotify shows only the festival start day for multi-day events, that is common partner behavior — put day-specific notes on your site if fans need which day you play.
• Support slots: list the show under your artist with accurate billing; do not invent headliner ticket URLs you do not control.
• Co-headline tours: one event per night per artist profile, shared ticket URL is fine — two conflicting ticket vendors is not.

When in doubt, the owned /tour page is allowed to be clearer than the platform widget. Clarity still must come from the same underlying dates.

Cache, CDN, and “I updated it but the site didn’t”

After an edit upstream:

1. Hard-refresh the Tour page (and homepage module).
2. If you use a custom API layer with caching, set a short TTL for events (minutes, not days) during announce weeks.
3. Confirm you edited the production BIT/Tourbox artist, not a duplicate unclaimed profile.
4. For Bandcamp, use their refresh control if the sidebar lags after a Tourbox edit.

If the widget is correct on a blank HTML test page but wrong on your site, you are caching or embedding the wrong artist id — not “Bandsintown being slow.”

FAQ

Should I embed Bandsintown or Songkick?

Embed whichever platform is your source of truth. Bandsintown if BIT owns the calendar; Songkick Tourbox widget if Tourbox owns it. Embedding both without a single write surface doubles the drift.

Why do wrong shows appear on Bandcamp?

Bandcamp pulls from Songkick and can match the wrong artist when names collide. Pin your Songkick Artist ID or artist URL in Bandcamp’s Upcoming Shows settings so only your Tourbox listings appear.

Can my homepage pull the next three dates automatically?

Yes. Use the widget display limit, an API query, or a CMS sort by date with a limit of three, then link to the full Tour page. Design an empty state for off-season.

What about sold-out waitlists and presales?

Keep status on the source listing (presale, on sale, sold out) and put waitlist/email capture on your site. Do not leave a live Buy Tickets CTA after the room is gone.

How do I handle TBA venues?

List city and date with venue TBA on the same event record; add the venue and ticket link when real. Avoid duplicate TBA and confirmed listings for one night.

What breaks when I hard-code dates in the design?

Stale ticket links, canceled shows that still look live, and a designer bottleneck every time the routing changes. Hard-coded tours age in public.

CTA

One calendar. Many readers. No five-login tour week.

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