A submission CRM is only useful while its festival records are current. Dates move, submission windows close, fees change, and links that worked during planning can become stale before a team is ready to submit. Festival API can provide the structured source layer that keeps a CRM useful without turning every weekly review into manual research.
This tutorial shows a practical sync pattern: keep your team’s notes and decisions in your own system, regularly refresh the fields Festival API owns, and make every change reviewable before it affects a submission plan.
Split source facts from team decisions
The first rule is simple: do not let an automated import overwrite the work your team has already done. A festival name, location, dates, deadlines, fees, categories, and submission link are source facts. Priority, relationship notes, previous correspondence, internal owner, and the decision to submit belong to your CRM.
Create a stable mapping between a Festival API record and your local record. Store the API identifier when it is available, plus a normalized name and location as a fallback. That gives you a reliable join key without relying on a staff member to recognize every spelling variation.
{
"festival_api_id": "festival_123",
"crm_status": "researching",
"internal_owner": "[email protected]",
"project_fit_note": "Regional premiere policy needs confirmation",
"last_synced_at": "2026-08-18T16:00:00Z"
}
Start with a focused pull, not your entire database
A first sync should begin with the festivals that are actually in play. Query the fields and filters described in the Festival API documentation for records that match your project’s countries, format, genre, date range, or current submission needs. A focused candidate set is easier to inspect and cheaper to operate than a blind full-database refresh.
For a weekly workflow, pull records connected to open CRM opportunities and a second set of festivals whose next deadline falls inside a planning window. The exact endpoint and available parameters can evolve, so keep query construction in one service module and use the current docs as the contract.
candidates = festival_api.list_festivals(
country="US",
active=True
)
for festival in candidates:
if festival.id in crm.open_festival_ids():
queue_for_sync(festival)
Normalize values before comparing them
API data and CRM fields often represent the same fact differently. A blank fee is not necessarily zero. A deadline may need a timezone. A location may be a city and country in one system and several structured fields in another. Normalize each field into a comparison-friendly form before deciding that a record changed.
- Convert dates to a consistent timezone and ISO representation.
- Store monetary values with their currency and distinguish unknown from free.
- Trim and normalize URLs before flagging a link change.
- Keep raw source values alongside normalized values for auditability.
This small layer prevents noisy updates. Without it, a formatting difference can create a false alert every time the sync runs.
Use a change queue instead of silent overwrites
Some changes should update automatically, while others deserve a human review. A festival address correction may be safe to apply. A deadline moving earlier, a fee increasing, or a submission URL changing can alter a producer’s plan. Send those changes to a queue with the old value, new value, source timestamp, and the affected projects.
{
"festival_api_id": "festival_123",
"field": "regular_deadline",
"old_value": "2026-09-15",
"new_value": "2026-09-01",
"action": "review",
"affected_projects": ["river-city"]
}
A review queue also makes the system trustworthy. Your team can see what changed and why a recommendation moved, rather than discovering a surprise after a deadline has passed.
Make the weekly report actionable
The deliverable is not a successful sync log. It is a short operational report: deadlines that moved, festivals that became newly relevant, records missing a direct submission path, and candidates that need a quick verification. Send it to the person who owns submissions and link each item back to the local CRM record.
Useful report sections include:
- Act this week: approaching deadlines or changes that require a decision.
- Review: fee, eligibility, date, or URL changes that affect active projects.
- New matches: festivals that meet saved project criteria but are not yet in the CRM.
- Data follow-up: records with incomplete information that need a source check.
Keep an audit trail for every decision
Save the source payload hash or retrieval timestamp, the fields compared, the resulting change record, and the reviewer’s action. This is valuable when a client asks why a festival was removed from a shortlist or when a team needs to reconstruct a prior submission decision.
Festival API supplies structured data, but no API should replace professional judgment about premiere rules, eligibility, or fit. Treat the sync as a way to surface facts sooner, then verify the important details at the festival’s official submission page before paying or submitting.
Build from a small reliable loop
Start with one project, a small set of active festivals, and a weekly review report. Once that loop is trusted, add saved searches, owner notifications, and a dashboard of unresolved changes. Teams that need larger volumes or production access can review the available plans on the Festival API pricing page.
The durable result is a CRM that remembers your team’s thinking while Festival API helps it keep pace with the changing festival landscape.