A submission list becomes difficult to manage when nobody can answer a basic question: why was this festival added, held, or ruled out? A spreadsheet may record a name and a fee, but it often loses the search criteria, the data snapshot, and the judgment behind the next action. Festival API can provide the structured record for a practical submission decision log.
This pattern is for producers, submission consultants, and developers building internal tools. It does not ask an API to decide where a film should submit. It creates a durable record of what the team saw at a particular time, what constraints applied, and what a person decided to do next.
Use search results as evidence, not the final decision
Start with a saved search that describes the project’s current constraints. GET /v1/festivals supports filters including category, country, genre, deadline window, maximum fee, state or province, and submission platform. The list response includes fields such as the festival ID, name, location, categories, genres, regular deadline, regular fee, submission URL, website, and composite score.
curl -G https://festivalapi.com/v1/festivals \
-H "Authorization: Bearer $FESTIVAL_API_KEY" \
--data-urlencode "category=short_film" \
--data-urlencode "deadline_after=2026-09-27" \
--data-urlencode "fee_max=50" \
--data-urlencode "sort=deadline" \
--data-urlencode "sort_dir=asc"Festival API returns a paginated result object with count, page, per_page, total_pages, and results. That makes it possible to store the exact query and a small snapshot of the fields that motivated a review. Do not reduce this step to a yes-or-no recommendation. A record can be eligible according to the search but still require a producer’s judgment.
Give every candidate a stable decision-log record
A useful record links a project to a Festival API festival ID and separates source data from team-owned notes. The source snapshot explains what the API returned. The decision fields explain what the team chose. Keeping those responsibilities separate prevents a later refresh from overwriting the reason a producer chose to wait.
{
"project_id": "short-doc-042",
"festival_id": 301,
"query_snapshot": {
"category": "short_film",
"deadline_after": "2026-09-27",
"fee_max": 50,
"sort": "deadline",
"sort_dir": "asc"
},
"festival_snapshot": {
"name": "Example Film Festival",
"country": "United States",
"deadline_regular": "2026-10-15",
"regular_fee": 35,
"submission_url": "https://example.com/submit"
},
"status": "review",
"decision": "hold",
"decision_reason": "Deadline and fee fit the current plan; producer review is still needed.",
"reviewed_at": "2026-09-27T16:00:00Z",
"reviewed_by": "[email protected]"
}The festival name in this example is deliberately generic. In a real workflow, populate the snapshot from the API response and retain the returned festival_id. Use your own project identifier and team member identity. The log is an operational record, so the fields that describe a human decision belong to your application, not the API.
Choose a small, explicit status vocabulary
Status drift creates ambiguity fast. A short controlled vocabulary is more useful than a large set of labels. One workable starting point is:
- review: the result meets first-pass constraints and needs a person to assess it.
- hold: potentially suitable, but waiting on a project, budget, or timing decision.
- submit: approved for submission by the responsible person.
- submitted: submission completed, with the confirmation stored separately.
- declined: intentionally not pursued, with a concise reason.
- refresh: source fields changed or need to be checked again before action.
Keep decision separate from status if you need both. For example, a team can decide to submit while the workflow is still waiting for the actual submission to be completed. This avoids treating an intention as a finished action.
Refresh facts without rewriting history
Deadlines, fees, and submission links can change. Before moving a record from review or hold to submit, request the individual festival record with GET /v1/festivals/{id} and compare the action-relevant fields with the saved snapshot. The detail endpoint includes submission information, categories, the primary deadline, standard fee, and festival details.
curl https://festivalapi.com/v1/festivals/301/ \
-H "Authorization: Bearer $FESTIVAL_API_KEY"When a relevant field differs, append a new refresh event rather than replacing the old snapshot. For example, record that the regular fee changed, that a deadline is now outside the planned window, or that the submission URL needs review. A decision log is useful precisely because it preserves the earlier context while making the current state visible.
Make the handoff clear
The most valuable output is often a simple producer handoff view: festival name, current deadline, current fee, direct submission link when available, decision status, owner, and next action. Link the row to the raw Festival API record or retain a JSON snapshot for auditability. Add a separate confirmation field only after someone completes a submission.
For deeper fit research, the roster endpoint is separate from festival details and returns previously screened films with fields such as title, director, year, and award. That evidence can inform a note, but it should not become an automatic acceptance prediction. The final submission decision remains a creative and strategic call.
Start with one project and one review loop
You do not need a full submission platform to make this valuable. Begin with one saved Festival API query, a table keyed by festival ID, and a weekly refresh for records that are still open. The decision log will reveal where the real friction is: unclear project constraints, budget approvals, missing submission materials, or stale source data. Build more automation only after that loop is reliable.
Review the complete filters, response fields, and endpoint costs in the Festival API documentation. When you are ready to run recurring searches and detail refreshes, see Festival API pricing to plan credits around the workflow you actually use.