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.

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. I do not attach invented sell-out counts or “X% more ticket clicks” to those sites. The receipt is the architecture: one calendar, many readers.

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). It does not display Songkick. Treat Spotify as a read surface.
• TBA, presale, sold-out, and canceled are status fields on the source — not 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 a Spotify partner path	Official widget or events API	Site, Spotify (when the listing qualifies), 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.

Write-surface test (answer out loud, then pick):

1. Who will add a date at 11:40 p.m. the night a hold confirms?
2. Will they open Bandsintown, Tourbox, or Webflow Editor?
3. If the answer is “whoever is awake,” you do not have a source of truth yet.

That person’s tool wins. Taste does not.

How do Spotify and Bandcamp fit?

They are readers, with different pipes. As of August 2026 the vendor docs still disagree in a way that matters.

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. Adding concerts to Spotify is explicit: list the show with a ticketing partner; Spotify imports it. Bandsintown is on that partner list. The same article states “We don’t display events from Songkick.” Required fields: at least one artist name, start time, venue name, event name. Virtual events are excluded. Spotify’s Live Events page still tells artists whose ticketer is not a partner to upload via Bandsintown so a listing can generate on Spotify.

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; Songkick will not get you there
Link-in-bio	Rarely	Manual or smart link	Point to /tour or the 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.

If Bandcamp is a real fan surface and you need Spotify Live Events, you are not choosing “BIT or Songkick” as a vibe. You are choosing a write tool and then covering the other pipe:

You need	Write in	Also maintain
Bandcamp sidebar + site widget	Songkick Tourbox	A partner listing (often BIT) if Spotify matters
Spotify Live Events + site widget	Bandsintown (or another Spotify partner)	Songkick if Bandcamp matters
Site only	Either, or a CMS	Nothing — say that out loud

Two write surfaces is the old five-login problem wearing a nicer jacket. Prefer one human updating one dashboard, plus a one-time ID pin on the other platform — not two full calendars.

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 August 2026)
Bandsintown widget	BIT is source of truth	Customize colors/fonts; data-display-limit, data-events-to-display / data-events-to-hide, country/continent filters
Bandsintown API	You need a fully branded list inside your design system	Events endpoint via app_id; managers still edit in BIT
Songkick Tourbox widget	Songkick is source of truth	Integrations → Your website → paste code; Tourbox edits 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

BIT’s own widget customization table is the attribute list I actually use on builds:

Attribute	What it does	Default to watch
data-artist-name	Artist page name or id_{artist_id}	Name collisions; prefer ID
data-display-limit	Caps visible rows; “Show all dates” appears if you exceed it	Default is show all — homepage should not
data-display-past-dates	Past dates in the same list	Default true — turn off on an “Upcoming” module
data-display-start-time	Show time next to the date	Default false
data-display-play-my-city	Play My City capture at the bottom	Off if it fights the brand system
data-display-logo	BIT logo at the top	Off when the film-grade type system cannot absorb it
data-countries / data-continents	Filter the list	Use for region-specific landing pages, not as a second calendar

BIT setup help is blunt: if the widget flakes, swap the artist name for the numeric ID from the public Bandsintown URL (/a/1025408 becomes id_1025408 in their example). Remove leftover BIT plugins and old header scripts. Two widgets on one page is how you get a blank hole and a support ticket that blames “Bandsintown being down.”

For film-grade artist sites, API or a 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 industry packet on the EPK bookers can scan: bookers need the same dates, not a second typed list.

How do you pin the right artist ID?

Most “wrong dates” bugs are identity bugs. The widget or Bandcamp matched a different act with the same name.

Surface	How you pin identity	Failure if you skip it
Bandsintown widget	data-artist-name="id_123456" from the /a/{id} URL	Widget shows the other “Foxtide”
Bandsintown API	https://rest.bandsintown.com/artists/id_{{artist_id}}/events/?app_id=...	Name lookup returns the wrong catalog
Bandcamp	Songkick Artist ID or full Songkick URL in Upcoming Shows	Tonga-class phantom dates
Songkick Tourbox widget	Code from your Tourbox Integrations page	You pasted a leftover artist’s snippet

Checklist before you ship the embed:

• Public BIT URL and Tourbox URL both resolve to this act
• Widget / API uses id_ form, not a display name
• Bandcamp Upcoming Shows has the numeric Songkick ID pasted and saved
• No second BIT or Songkick profile left unclaimed for the same spelling
• 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.

Can the homepage pull the 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 data-display-limit; their customization docs say a “Show all dates” link appears when you exceed the cap. CMS queries sort by date ascending and slice three.
3. “All dates” links to /tour (or your Tour route) — not to Bandsintown.com as the primary CTA.
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
EPK	Next few + “full routing” link	Booking contact, not fan ticket UX

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

API-shaped homepage (when the widget cannot match the type system):

1. Request upcoming events only — BIT’s API docs let you filter upcoming, past, all, or a date range.
2. Sort by start datetime ascending.
3. Render three rows: date, city, venue, status, ticket or notify CTA.
4. If the offers array is empty, BIT’s own guidance is a Notify Me trigger (&trigger=notify_me) instead of a fake Buy button.
5. Cache for minutes during announce week, hours in the off-season — not days.

Empty offers is a state. It is not a reason to paste last tour’s Ticketmaster URL.

How do sold-out, waitlists, and presales stay honest?

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

Tourbox documents a dedicated sold-out control for the website widget in the same help cluster as the embed. Use it. Do not hide a sold-out room by deleting the event if fans still need a waitlist path.

BIT’s API CTA table is useful when you build the list yourself:

API signal	Button on the site
Ticket / offer URL present	Buy / Tickets
No offer	Notify Me (trigger=notify_me)
Always available	RSVP (trigger=rsvp_going)
Artist follow	Track (trigger=track) — only if you want BIT’s list, not your own

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 do you 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
• Spotify requires a venue name to import. A TBA listing may sit on your site and Bandcamp and still be invisible on Spotify until the room is real. That is partner policy, not a broken embed.

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

If the graphic needs a city lock before the venue lock, generate the graphic from the listing. Do not invent a venue so the poster looks finished.

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
Canceled show still live	You are advertising a room that does not exist

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.

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. Did the CTA change?
• Is there an off-season empty state, or a 2024 date still labeled Upcoming?

If any box fails, you do not have a tour system. You have a brochure.

What does a manager workflow look like in 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 — missing-concerts help says listings should appear within 24 hours of a partner listing, and that it can take a few days. After that, contact Spotify with the event link and the artist profile. Wrong date/time/venue is fixed at the ticketing partner, not inside Spotify for Artists.
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.

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 act with your name
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.

When is a CMS honest instead of a widget?

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.

Cap fields. Date, city, venue, ticket URL, status, optional note. No “layout mode.” If the manager can invent a new homepage from a tour row, you built a page builder and called it a calendar.

Field	Required	Why
start (datetime, timezone explicit)	Yes	Sort, schema, “next 3”
city	Yes	Homepage can render before venue locks
venue	No (TBA allowed)	Empty ≠ “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 seat, not Designer. The person who updates dates on Tuesday should never be able to break the fold.

Do festivals and support slots need a different listing?

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.
• Spotify’s concerts and festivals article : multi-day festivals show the first day as the event date unless each day is listed as a separate event on the ticketing partner site. Put day-specific notes on your site if fans need which day you play.
• Tourbox festival “Pick day” sets the performance date on your website widget only. The Songkick event listing still shows the full festival range. Do not assume every reader got the Tuesday set time.
• 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.

Listing type	Write once as	Site may add
Club date you control	Your event + your ticket URL	Opener / door time
Festival	Official fest event, you linked as artist	“We play Saturday” note
Support slot	Your artist + accurate billing	“Tickets via headliner” if that is true
Multi-night residency	One event per night	Series label in note

Do not scrape a festival Wikipedia page into the CMS. That is how Saturday’s set becomes Friday on the homepage.

Why did I update it but the site didn’t change?

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.
5. For Spotify, wait the documented window, then treat it as a partner-data problem — not a site-embed problem.

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.”

Symptom	First check	Not the first check
Site stale, BIT/Tourbox correct	CDN / page cache / old embed snippet	“The API is down”
Widget blank	Artist ID vs name; leftover plugin	Redesign the Tour page
Bandcamp shows another act	Songkick ID field empty	Retype dates into Bandcamp
Spotify missing after 24h–few days	Partner listing fields (name, start, venue, event)	Paste dates into Spotify for Artists
Two rows for one night	Duplicate TBA + confirmed	A new CMS collection

Should the site emit Event schema?

Sometimes. Not as a second calendar.

schema.org/Event is the vocabulary: startDate, location, offers, eventStatus. Google’s event structured-data docs want a leaf URL per event, not a 40-date index, if you care about Google’s event experience. They also want timezone offsets on startDate (2019-09-05T19:00:00-05:00 in their New York example), and they exclude virtual-only events.

Approach	When it is honest	When it lies
No extra schema; widget only	Most artist homepages	You promised Google rich results you will not maintain
JSON-LD generated from the same API/CMS as the page	Custom /tour/city-date leaves	Markup written by hand in the template
Status mapped from the listing	EventCancelled / EventPostponed / EventRescheduled when the source flips	EventScheduled left on a canceled room
offers.availability	SoldOut when the listing is sold out	InStock because the ticket URL still 200s

Google’s own technical note: do not treat a schedule index as the event page. If you will not ship per-show URLs, skip the rich-result chase. A correct widget on /tour still beats decorated JSON-LD that says the Friday room is on sale.

Timezone rule I actually enforce: store the local offset on the event. “7pm” without a zone is how a West Coast announce graphic and an East Coast widget disagree by three hours.

Who owns the login when the team changes?

Tour calendars die at handoff. Manager leaves. Intern created the BIT account with a personal Gmail. Label “has access” and nobody can reset it during announce week.

Seat	What they may do	What they may 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
Social	Link to /tour	Maintain a fourth list in Stories

Handoff checklist (do this at contract start, not after the first missed date):

• BIT / Tourbox login lives on a shared studio or management inbox, not a personal one
• 2FA recovery codes sit in the same password manager as the domain DNS
• Artist IDs (BIT numeric, Songkick numeric) are written in the brand doc
• Embed snippet in the repo or CMS is the production ID, commented
• Offboarding revokes the departing manager before you announce the next run

I have shipped hundreds of production sites. The tour module that survives is the one a tired manager can update from a phone without calling the designer. Cinema on the fold is a different job. Dates are ops.

Re-verify the Bandcamp↔Songkick pin and the Spotify partner list at the start of every major tour cycle. Partnerships move. Do not trust a setup from two albums ago.

How do you pick the stack this week?

Answer in order. Stop when the next question does not apply.

1. Who updates dates weekly? → their tool becomes source of truth.
2. Is Bandcamp a real fan surface? → Songkick ID pinned, Tourbox accurate.
3. Do you need Spotify Live Events? → listings must flow through a current Spotify ticketing partner. Songkick will not do it. BIT is one path 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.
6. Is the link-in-bio still a handwritten date list? → delete it. Point at /tour.

Doors vs show time (one line, same listing):

You know	Store	Show on site
Doors 7, show 8	Start = show 8 with offset; note = “doors 7”	Date + 8pm + doors in the note
Festival set 4:20	Start = 4:20 if the partner allows it; else festival day + note	Day + set time on /tour
TBA time	Date only; no fake 8pm	Hide the clock until it is real

A fake 8pm “for the poster” is how a fan misses the set. Same rule as fake venues.

If two people still insist on “just updating Instagram first,” the site will lose. Social is a reader. The listing is the write. Post the graphic after the event exists in BIT or Tourbox, not before.

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. If you need Bandcamp and Spotify, pin Songkick for Bandcamp and keep a partner listing (often BIT) for Spotify — still one human typing dates once.

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. Bandcamp’s help text is the Tonga joke for a reason: name match is not identity.

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. Turn past dates off on the homepage module so last year’s room does not sit under “Upcoming.”

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. If the API returns no ticket offer, show Notify Me — not last tour’s URL.

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. Expect Spotify to stay blank until the listing has a real venue name, start time, and event name.

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. If a manager cannot change a date without opening Designer, the site is already lying to someone.

CTA

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

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