How to Compare Submission Fees, Deadlines, and Geography with Festival API

Most festival research gets messy when three variables collide at once: where a festival is located, what it costs to submit, and whether the deadline still fits the project schedule. Teams usually track those details in separate tabs or spreadsheets, then spend more time reconciling the list than improving the shortlist. A better approach is to treat geography, fees, and timing as one workflow from the start.

Festival API is a practical fit for that job because the core list endpoint already exposes filters that map to real submission planning. You can begin with broad discovery, narrow by country or state, cap fees, constrain deadlines, and only spend detail calls on the few festivals that survive the first pass. If you want the endpoint reference open while you build, start with the Festival API docs. If you are estimating usage for a tool or internal workflow, the pricing page shows the credit costs clearly.

Why these three filters belong together

Each variable matters on its own, but the decision usually happens at the intersection.

• Geography shapes premiere strategy, travel practicality, and regional audience goals.
• Submission fee keeps the shortlist grounded in a real budget.
• Deadline timing determines whether a festival is actionable now or should wait for a later cycle.

A list that ignores any one of those can look impressive and still be unusable. Fifty active festivals do not help much if half are outside the target regions, a quarter are already too close to deadline, and the remaining group blows through the budget. The goal is not to find the biggest list. The goal is to find the best next options.

Start with a discoverable filter model

For most applications, you should not hardcode countries, states, or category labels into the interface. Pull the available options from the API so the UI reflects the actual dataset.

Festival API makes that straightforward with lightweight lookup endpoints:

• GET /v1/categories/ for available category codes such as short_film, documentary, or animation
• GET /v1/countries/ for country lists with counts
• GET /v1/states/ when region-level filtering matters inside a country

Those endpoints are cheap compared with repeated detail calls, and they help you build forms that stay in sync with the data instead of drifting into free-text chaos.

Use the festival list endpoint for the first pass

The cheapest and most scalable place to compare fees, deadlines, and geography is the main festivals endpoint. According to the docs, GET /v1/festivals/ costs 1 credit, which makes it the right place to do broad filtering before you enrich anything else.

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://festivalapi.com/v1/festivals/?category=documentary&country=Canada&deadline_after=2026-08-01&deadline_before=2026-11-30&fee_max=60"

That one request already answers a practical question: which documentary festivals in Canada are still accepting submissions within a reasonable date window and below a clear fee ceiling?

You can repeat the same pattern across multiple countries or regions and merge the results into one comparison table in your application.

Build a comparison workflow instead of a single search box

A practical submission planner usually works in stages:

1. Choose a project profile, such as category, preferred countries, budget ceiling, and target deadline window.
2. Run one or more list queries against /v1/festivals/.
3. Normalize the returned festivals into a single internal shape.
4. Sort or group them by geography, fee band, and deadline urgency.
5. Only call /v1/festivals/<id>/ for finalists that need deeper review.

This pattern matters because detail lookups cost more than list calls. You get a better result, and a more efficient credit profile, by filtering wide first and enriching late. That is especially true if you are building a dashboard, a filmmaker assistant, or an internal analyst workflow where users will refine the shortlist several times before they commit.

Represent geography as more than a single country dropdown

Geography is often the most under-modeled part of festival planning. A team may want one of several different strategies:

• Stay domestic to control travel and marketing cost
• Target a few prestige countries for exposure
• Focus on a region with audience or language relevance
• Mix nearby practical choices with a handful of reach festivals

That means your app should usually support more than one geographic mode. One useful pattern is to separate:

• Primary countries that should rank highest
• Allowed countries that can stay in the pool
• Excluded regions that are not practical this cycle

You can start with /v1/countries/ to populate the option list, then use repeated /v1/festivals/ calls to build country-specific pools. If regional logic matters inside the United States or Canada, /v1/states/ gives you a cleaner way to narrow the scope without asking users to type location names manually.

Treat fees as a decision boundary, not a nice-to-have field

Many filmmakers work from a fixed submission budget, not an abstract preference. That changes the product design. Instead of showing fees as passive metadata, make them part of the filtering and ranking logic.

Useful fee handling patterns include:

• Hard cap: exclude anything above the maximum using fee_max
• Fee bands: group festivals into low, medium, and premium ranges for easier review
• Budget remaining: estimate how many submissions are still feasible after each shortlist decision
• Value review: flag higher-fee festivals that still deserve review because geography or category fit is unusually strong

If you are building for submission consultants or producers, that budget visibility is often the difference between a shortlist that gets approved and one that gets trimmed down in a later meeting.

Convert deadlines into urgency buckets

Raw dates are useful, but urgency buckets are usually easier to act on. After you pull festivals from the list endpoint, transform the deadline into categories such as:

• Immediate: due within 14 days
• Soon: due within 15 to 45 days
• Later: due beyond 45 days

This lets you show the same festival data through a workflow lens instead of leaving users to scan date strings manually. It also works well with reminders, watchlists, and weekly refresh jobs.

If you need the queue to stay fresh, rerun the same filtered searches on a schedule and compare the result set against your stored shortlist. That makes it easy to detect when a deadline window closes, a fee now exceeds the project threshold, or a previously marginal festival should move into review.

Only enrich the finalists

Once a smaller candidate set survives the geography, fee, and deadline pass, then it makes sense to spend more credits on deeper inspection. Use GET /v1/festivals/<id>/ for richer detail and GET /v1/festivals/<id>/roster/ when you want to understand what the festival has screened before.

That final enrichment step is where a basic comparison tool becomes a serious research workflow. A shortlist can start with twenty plausible records, then narrow to five that deserve closer editorial judgment. Festival API helps you reserve the expensive inspection step for the moments when it actually matters.

A simple internal data shape

You do not need a complicated schema to make this useful. A small internal model can carry the whole comparison flow:

{
  "festival_id": 301,
  "name": "Example Documentary Festival",
  "country": "Canada",
  "state": "Ontario",
  "deadline": "2026-10-15",
  "submission_fee": 45,
  "category_match": true,
  "urgency_bucket": "soon",
  "geo_priority": "primary",
  "notes": []
}

From there, you can sort by urgency, group by country, filter by fee band, and attach human notes without losing the original API context.

Where this workflow fits best

This approach is useful for more than one audience:

• Filmmaker platforms that want structured shortlist building inside the product
• Submission consultants who need repeatable client research
• Producer tools that compare festival strategy against budget and travel constraints
• AI assistants that need clean filters before they generate recommendations or action lists

The common theme is that none of these users want a giant raw directory. They want a narrow, defensible set of next actions.

Keep the workflow explainable

The best submission tools do not just return a ranked answer. They show why a festival is still in the pool. If a festival made the shortlist because it is in a target country, below the fee ceiling, and still open for another 30 days, that explanation builds trust. It also makes it easier for a filmmaker or producer to override the system when the context changes.

That is one of the quieter advantages of structured filtering. It keeps your logic legible. You can tell the user exactly how the pool was narrowed, and you can update the rules without rebuilding the entire workflow.

Final takeaway

If you want Festival API to become part of a real submission planning tool, start by combining geography, fees, and deadlines in the first-pass search. Use the low-cost endpoints to shape the candidate pool, enrich only the finalists, and keep the shortlist grounded in actual budget and timing constraints. That gives filmmakers and builders a workflow that is simpler to trust, cheaper to operate, and easier to turn into repeatable action.