Festival research is rarely blocked by a lack of results. It is blocked by uncertainty: a deadline is missing, a fee looks stale, a category does not match the project, or a submission path needs a human check. If you are building a filmmaker product or managing submissions internally, treating every record as equally ready creates unnecessary work.
A data quality queue gives that work a clear order. With Festival API as the structured source, you can identify relevant festivals, define which fields matter for a given workflow, flag records that need review, and keep incomplete data from quietly becoming a recommendation. The result is not a claim that every festival record is perfect. It is a practical system for knowing what to trust, what to verify, and what to show next.
Start by defining “ready enough”
Data quality is contextual. A festival record that is good enough for a broad discovery page may not be ready for a submission call to action. Before writing a score, define the minimum information a record needs for the decision your product is making.
- Discovery-ready: festival name, location, basic categories, and an active status signal.
- Shortlist-ready: a relevant category match plus usable deadline and fee information.
- Submission-ready: a direct submission destination or a verified path that a filmmaker can act on.
- Reporting-ready: normalized country, dates, categories, and enough metadata to compare records consistently.
This is why a single completeness percentage is often not enough. Store the reason a record was flagged, not only a final score. A filmmaker can make a good judgment when they see “deadline needs confirmation.” A generic “72 percent complete” label is far less useful.
Pull a focused candidate set first
Do not run quality checks against every festival when the user only needs a documentary shortlist for specific countries and a defined submission window. Use Festival API filtering to form the candidate set, then assess the returned records against your own requirements. The available filters and record fields are documented in the Festival API docs.
For example, a project profile might contain target format, genres, preferred regions, a latest acceptable deadline, and a fee ceiling. That profile narrows discovery. Your quality layer then answers a different question: is each remaining record complete enough to be presented or acted on?
project = {
"categories": ["documentary", "short"],
"countries": ["United States", "Canada"],
"max_fee": 60,
"must_have": ["deadline", "submission_url"]
}
candidates = festival_api.search(project)
The exact request shape depends on the endpoint you choose. Keep the project rules in your application rather than embedding them in display logic, so they remain explainable and easy to change.
Turn missing fields into review reasons
For each candidate, evaluate the fields that matter to the workflow. A simple review object can preserve both the outcome and the reason behind it.
def review_record(festival):
reasons = []
if not festival.get("deadline"):
reasons.append("missing deadline")
if festival.get("submission_fee") is None:
reasons.append("missing submission fee")
if not festival.get("submission_url"):
reasons.append("missing direct submission link")
if not festival.get("categories"):
reasons.append("missing categories")
return {
"ready": len(reasons) == 0,
"reasons": reasons,
"priority": len(reasons)
}
Use the dedicated submission_url when your experience needs a direct next step. It is more reliable than assuming a general website is also the right place to submit. If the field is absent, route the record to a review state instead of presenting a confident-looking button that sends users somewhere unhelpful.
Prioritize the queue by user impact
Not every gap deserves the same urgency. A missing social link may not affect a submission decision. A missing deadline can. Sort the queue by the impact of the gap, then by the opportunity value of the festival for the current project.
- Flag records that could cause a missed deadline or a broken submission step.
- Next, flag records whose fee or category data could change shortlist ranking.
- Then handle descriptive gaps that affect presentation but not an immediate decision.
For a team workflow, assign the record to a reviewer and retain a timestamp for the last check. For a customer-facing product, show a gentle status such as “details to verify” and give users a way to save the festival without overstating certainty.
Separate source data from your derived judgment
Festival API should remain the source for structured festival information. Your application should own derived fields such as quality_status, review_reasons, last_checked_at, and project-specific fit. That separation makes updates safer: when fresh API data arrives, you can re-evaluate the record without losing your team’s notes or workflow state.
It also makes the interface more honest. A festival can be an excellent match for a project while still needing one detail checked. By showing fit and completeness as separate ideas, you avoid hiding useful opportunities and avoid treating unknown facts as known ones.
Recheck only what can change
Deadlines, fees, submission URLs, and active status are the fields most likely to change on a useful cadence. Keep a snapshot of the fields you use in decisions, then compare later API responses. When a value changes, re-run the quality rules and notify only the users or reviewers affected by that festival.
This turns data maintenance into a lightweight operating loop: discover, assess, review exceptions, and refresh. It is more sustainable than periodically rebuilding an entire spreadsheet, and it creates a clearer experience for filmmakers who need to make decisions with limited time.
Build for transparent decisions
A good festival tool does not promise certainty where the underlying information needs verification. It helps people make better decisions by making the state of the data visible. Festival API provides the structured foundation; a data quality queue adds the product judgment that tells users which records are ready now and which ones need another look.
Start with a small set of required fields, capture specific review reasons, and test the queue with one real project profile. When you are ready to move from prototype to production, review the Festival API pricing options alongside the documentation.