Direct Submission Links: The submission_url Field

If you are building a filmmaker tool, a festival discovery app, or a submission workflow, one small ambiguity can break the whole user experience. You can show a festival card, rank it, save it, and even surface deadline data correctly, but the moment a user clicks Submit Now, the link has to go to the right place. Until now, that was harder than it should have been because a festival's general website and its actual submission page are not always the same thing.

Festival API now solves that with a dedicated submission_url field. Instead of guessing whether website points to a homepage, a FilmFreeway profile, or some buried submission page, you now get a direct link meant for the submission step itself. More than 7,700 festivals already have FilmFreeway submission URLs populated on day one, and more are being added each week across the 12,000+ festivals tracked in the API.

If you want to test the field in your own workflow, start with the Festival API docs and the live demo. The change is simple, but it unlocks a much cleaner product experience for anyone building around festival submissions.

The problem with using website for submission flows

Before submission_url, developers had to infer intent from the website field. Sometimes that worked. Sometimes it did not.

• A festival homepage might include news, archives, sponsors, and ticketing, but no obvious submission button above the fold.
• A FilmFreeway profile might function as both the public page and the submission destination.
• A festival could route submissions through a dedicated page on its own site that is separate from the main homepage.

That ambiguity creates friction everywhere a builder wants a direct call to action. A user sees a promising festival, clicks submit, lands on a general website, and now has to hunt around for the actual entry page. In product terms, that is a leaky funnel. In workflow terms, it is wasted time. In data terms, it means one field was being asked to serve two different jobs.

General site links still matter. They are useful for research, branding review, contact details, and broader festival context. But the submission action needs its own destination. That is exactly what submission_url provides.

What submission_url gives you

submission_url is a dedicated, clickable link to where a filmmaker actually submits a project. In many cases, that means a FilmFreeway profile such as FilmFreeway. In other cases, it can point to a direct submission page on the festival's own site.

That distinction matters because it lets developers model the user journey more honestly:

• website can remain the general reference URL
• submission_url can power the primary action button
• submission_platforms can help explain what submission system the user will encounter

Instead of guessing, your product can now label actions with confidence. If you want to show Submit on FilmFreeway, Apply Now, or Open Submission Page, you have a field designed for that exact purpose.

A simple example

Here is the new field in context:

GET /v1/festivals/1141/
{
  "name": "Accessible Film Festival",
  "submission_url": "https://filmfreeway.com/AccessibleFilmFestival",
  "submission_platforms": ["FilmFreeway"],
  "website": "https://filmfreeway.com/AccessibleFilmFestival"
}

In this case, the general website and the submission destination happen to match. That is fine. The point of the new field is not that the values must always differ. The point is that your application no longer has to assume they mean the same thing.

Once the fields are separated conceptually, your interface logic gets much cleaner. A research panel can link to website. A submission button can link to submission_url. And if only one is present for a given festival, your fallback behavior becomes explicit instead of accidental.

Who benefits from this field

This is useful for several kinds of builders:

• Filmmaker platforms that want a clean shortlist-to-submission workflow
• Festival discovery apps that rank and filter opportunities but also need a reliable next-step link
• Submission consultants who manage festival research for clients and need faster handoff into action
• Internal studio tools that track deadlines, priorities, and actual submission destinations in one place

The common thread is that these tools do not stop at discovery. They help people take action. Once a user decides a festival belongs on the shortlist, the next click matters. submission_url reduces the gap between finding a festival and entering it.

Why this improves product design

Small schema changes often have outsized interface consequences. This one affects product design in at least four practical ways.

1. Cleaner call-to-action buttons

You can now render a submission action based on a purpose-built field instead of heuristic guesswork. That means fewer misleading buttons and fewer dead-end clicks.

2. Better fallback logic

If submission_url exists, use it for the primary action. If it does not, you can choose to fall back to website, disable the action, or prompt the user that direct submission data is not yet available. The key difference is that the fallback is intentional.

3. More honest labeling

When paired with submission_platforms, your interface can describe the destination more clearly. A user who expects FilmFreeway should not be surprised by a generic homepage, and a user who expects a festival-hosted form should not be sent to a third-party listing without context.

4. Easier workflow automation

Agents, consultants, and internal tools can store a direct action link alongside deadlines, fees, and festival fit data. That makes task queues, reminder systems, and submission checklists more reliable.

Coverage on day one

This is not a placeholder field waiting for future population. More than 7,700 festivals already have FilmFreeway submission URLs populated on day one. That gives developers immediate coverage for a large share of active submission workflows, with more entries being added each week.

For teams evaluating whether the field is practical enough to integrate now, that day-one coverage matters. You do not have to wait for a theoretical future dataset. You can start using it now, measure where it appears in your own filtered results, and improve your UX immediately.

How to use it in your app

A straightforward implementation pattern looks like this:

1. Use list and detail endpoints to identify festivals that match the filmmaker's goals.
2. Display general festival information as usual, including title, dates, fees, and fit signals.
3. If submission_url is present, use it for the main submit action.
4. Keep website available as a secondary reference link for broader context.
5. Optionally use submission_platforms to label the destination or group festivals by platform.

That model works for lightweight directories, client dashboards, submission assistants, and more advanced agent workflows. It also gives you a cleaner data contract if your product supports exports, saved lists, or CRM-like follow-up steps.

A better fit for builder workflows

Festival API has always been most useful when it helps developers turn scattered festival information into clear actions. submission_url fits that philosophy well because it removes a layer of ambiguity right where products need confidence most.

Discovery is important, but the handoff into submission is where many filmmaker tools either become genuinely useful or quietly fall apart. A dedicated submission link helps products stay on the useful side of that line.

Final takeaway

If your product includes a shortlist, recommendation engine, consultant workflow, or festival submission queue, submission_url is a meaningful upgrade. It gives you a direct destination for the action users actually want to take, reduces guesswork around the website field, and makes your submission UX easier to trust. Explore the field in the docs, try it in the demo, and start turning festival discovery into a cleaner submission flow.