How to Build a Festival Submission Shortlist Dashboard with Festival API

Most festival research breaks down at the same point. You start with a decent list, then the list turns into tabs, notes, fee checks, deadline checks, and half-finished shortlists spread across spreadsheets and browser bookmarks. The problem is not a lack of festival information. The problem is that the workflow gets messy fast.

A shortlist dashboard fixes that. Instead of treating festival discovery as one-off search, you give yourself a repeatable interface: filter active festivals, save the ones that matter, add a little scoring or status logic, and review the finalists in one place. Festival API is a good fit for that job because the search step, the country and category lookups, and the final detail checks all map cleanly to API calls.

This article walks through a practical version of that workflow. The goal is not to build a giant platform. It is to build the kind of internal tool a filmmaker platform, submission consultant, producer, or assistant could actually use every week.

What the dashboard needs to do

At minimum, a shortlist dashboard should help you answer five questions:

• Which festivals are active right now for this kind of project?
• Which countries or regions should we focus on?
• Which options still fit the submission budget?
• Which deadlines are coming up soon?
• Which festivals deserve a closer second pass?

You can build that with a small stack of Festival API endpoints:

• GET /v1/categories/ for category dropdowns
• GET /v1/countries/ for country filters
• GET /v1/states/ if you want region-level filtering inside a country
• GET /v1/festivals/ for the main shortlist search
• GET /v1/festivals/<id>/ for deeper detail on finalists
• GET /v1/festivals/<id>/roster/ when programming history matters

If you are budgeting usage for a production workflow, check the current credit model on the pricing page before you wire everything together. The basic pattern is simple: search broadly with low-cost calls, then use detail and roster only on the small set of festivals that make the cut.

Step 1: start with live filter options

Do not hardcode category and geography filters if you can avoid it. A shortlist tool is easier to maintain when your dropdowns come from live API data instead of a stale constant in your frontend.

curl -H "Authorization: Bearer YOUR_API_KEY"   "https://festivalapi.com/v1/categories/"

curl -H "Authorization: Bearer YOUR_API_KEY"   "https://festivalapi.com/v1/countries/"

That gives you the data needed to populate a clean filter form. If your users tend to focus on a single country, you can also pull states or provinces dynamically:

curl -H "Authorization: Bearer YOUR_API_KEY"   "https://festivalapi.com/v1/states/?country=United%20States"

In practice, this is the first thing that makes the dashboard feel real. Instead of asking users to guess valid values, you let the API define the available choices.

Step 2: build the first-pass shortlist query

The main work happens in GET /v1/festivals/. This is where you narrow the pool to active options that match the project. For a short film with a budget cap and an upcoming deadline window, a first-pass query might look like this:

curl -H "Authorization: Bearer YOUR_API_KEY"   "https://festivalapi.com/v1/festivals/?category=short_film&country=Canada&deadline_before=2026-10-01&fee_max=50&sort=deadline"

That query already does a lot of useful cleanup. It removes festivals outside the category, trims the geography, enforces a price ceiling, and brings earlier deadlines to the top. If the user is in a hurry, the dashboard can be useful at this step alone.

A simple filter form can map directly to the API parameters:

• category for project type
• country and optional state for geography
• deadline_before and deadline_after for timing
• fee_max for budget control
• q for keyword searching
• sort=deadline when urgency matters more than alphabetical order

Step 3: save status, not just records

This is where many tools stop too early. A query result is not yet a working shortlist. You still need a lightweight workflow layer.

For each festival you save, store a few fields outside the API response:

• internal status such as considering, reviewing, finalist, or submitted
• notes about fit, fee concerns, or premiere strategy
• a saved-at timestamp
• optional owner if multiple people touch the shortlist

That gives you a dashboard instead of a read-only search page. You can keep this in a small relational table, an Airtable base, a Notion database, or even a local JSON-backed internal tool if the workflow is lightweight.

Here is a simple model shape:

{
  "festival_id": 301,
  "status": "finalist",
  "fit_score": 82,
  "notes": "Strong category fit, manageable fee, deadline in six weeks",
  "saved_at": "2026-07-10T12:00:00Z"
}

Step 4: add a transparent fit score

You do not need machine learning to make the shortlist better. A basic fit score usually goes a long way. The important part is that the score stays explainable.

For example, you might weight the shortlist like this:

• 40 points for category match
• 20 points for geography match
• 20 points for fee fit
• 20 points for deadline timing

That is enough to separate "maybe" from "worth a closer look." If you want a broader quality lens, you can also review the /v1/festivals/scored/ endpoint and compare those results with your shortlist logic. I would still keep the dashboard's own ranking visible and grounded in user intent. Teams trust recommendation logic more when they can see why a festival landed near the top.

Step 5: enrich only the finalists

Once you have a shortlist, do a second pass on the top candidates instead of enriching every result. This keeps the workflow cheaper and cleaner.

For a final review card, pull detail data only when a festival moves into the serious-consideration bucket:

curl -H "Authorization: Bearer YOUR_API_KEY"   "https://festivalapi.com/v1/festivals/301/"

If programming history matters, especially for filmmakers trying to judge fit, follow that with a roster lookup:

curl -H "Authorization: Bearer YOUR_API_KEY"   "https://festivalapi.com/v1/festivals/301/roster/"

This is the point where the shortlist becomes more than filtering. You can show a compact review screen with the festival profile, dates, fee context, and a look at previously screened films. That is often enough for a consultant, assistant, or producer to make a real decision.

Step 6: sketch the actual app flow

A practical shortlist dashboard can be built with a straightforward workflow:

1. User selects category, geography, deadline window, and fee cap.
2. The app calls /v1/festivals/ and returns the filtered list.
3. User saves promising festivals into a shortlist table.
4. The app assigns status and an internal fit score.
5. When a festival is promoted to finalist, the app calls detail and roster endpoints.
6. The dashboard shows notes, next actions, and submission status in one place.

If you are building this in Python, the official Python client is the fastest way to wire the data layer. If you are building in JavaScript, the Node.js client keeps the same workflow clean on that side.

Example Python sketch

from festivalapi import FestivalAPI

client = FestivalAPI("fes_your_api_key")

results = client.festivals.list(
    category="documentary",
    country="United States",
    deadline_before="2026-09-15",
    fee_max=60,
    sort="deadline",
)

shortlist = []
for festival in results["results"][:10]:
    shortlist.append({
        "festival_id": festival["id"],
        "name": festival["name"],
        "status": "considering",
    })

finalist_id = shortlist[0]["festival_id"]
detail = client.festivals.detail(finalist_id)
roster = client.festivals.roster(finalist_id)

You can wire that into Django, FastAPI, Flask, Next.js, or even a simple internal notebook-to-dashboard flow. The hard part is not the framework. The hard part is deciding which workflow questions matter most to your users.

Where this dashboard is useful

This pattern works well in a few obvious places:

• a filmmaker platform that wants saved shortlists and submission reminders
• a consultant workflow that needs client-by-client festival tracking
• a producer research tool used during launch planning
• an editorial or directory product that wants internal curation before publishing recommendations

It also works as a strong internal tool before you ever turn it into a customer-facing feature. That matters more than people think. A small internal dashboard is often the fastest path to proving whether a bigger product idea deserves more engineering time.

Final takeaway

If you want a useful Festival API walkthrough project, build a shortlist dashboard first. It stays close to real user behavior, it makes good use of the API's filter structure, and it creates a workflow your team can keep reusing instead of restarting research from scratch every time.

Start with categories and countries, run a focused search with /v1/festivals/, save only the promising candidates, and enrich the finalists with detail and roster data. That is enough to move from scattered festival browsing to a shortlist process that actually holds together.

For the endpoint details, start in the Festival API docs. If you want to estimate ongoing usage before building, review the current pricing options.