--- title: "Yodiz Integration" description: "Yodiz is agile project management and issue tracking: epics, user stories, tasks, issues, sprints and releases. Agents create and update stories, tasks and issues, plan sprints and releases, and keep the backlog in step with what is happening elsewhere." url: https://flowrunner.ai/integrations/yodiz date_modified: 2026-09-04T14:21:17-07:00 --- # Yodiz [Project Management](https://flowrunner.ai/integrations/category/project-management-productivity) Yodiz is agile project management and issue tracking: epics, user stories, tasks, issues, sprints and releases. Agents create and update stories, tasks and issues, plan sprints and releases, and keep the backlog in step with what is happening elsewhere. 45 actions · Session · available [Yodiz website](https://yodiz.com/) · [Vendor Site](https://www.yodiz.com/) · Capability data verified 2026-08-18 1. A batch of accepted requirements arrives from the product intake system 2. Get Project Metadata reads this project's own status codes once, and the agent reuses them for every item 3. List Project Users resolves each proposed owner to the identifier Yodiz expects everywhere else 4. Search Items reads back the identifiers already imported, in one call rather than one per record 5. Agent totals the requests the import would spend against what the account has left for the day 6. Agent posts the projected request cost alongside the duplicates it found and the flows already scheduled to run 7. The product owner decides whether the import runs now, runs trimmed, or waits for the daily counter to reset ## What This Integration Enables Yodiz is agile tracking with a full backlog hierarchy behind it: epics hold user stories, stories hold tasks, issues sit alongside them, and sprints and releases cut across both. That structure is generous. The API around it is deliberately not, and designing for Yodiz means designing for that. It publishes no webhooks, so a workflow polls. It caps the account at a few hundred requests a day. Statuses are defined per project and per item type, so there is no global vocabulary to hardcode. None of this is a defect; it is simply an API that rewards workflows built to be economical and punishes ones built to be chatty. FlowRunner agents are built the economical way here. They read a project's metadata once and reuse the status codes rather than fetching them per item. They use Search Items and List User Story Subitems to read a whole sprint's detail in a handful of calls instead of one call per record. They ask for the fields they need rather than everything. And because an unknown route in this API answers with a success and an empty body rather than an error, agents confirm consequential writes by reading them back instead of trusting the response. Where the day's remaining budget is the constrained resource, spending it is a decision, and decisions with shared consequences are where a [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) step belongs. ### Without FlowRunner **Backlog kept in step by hand**: Accepted requirements are retyped as stories, and the two lists drift within a week **Status codes guessed**: An integration writes a status value that another project does not define, and the write is refused **Automation competes with itself**: Several flows hit the same account and the day's allowance is gone before the important one runs ### With FlowRunner **Requirements arrive as structured work**: Stories, tasks and their owners are created from the source with the project's own vocabulary **Status codes read from the project**: The project's metadata is read once per run and reused, so every write uses a value that exists **The request budget is planned, not discovered**: The cost of a run is calculated and approved before it is spent ## Use Case Scenarios ### A backlog import that knows what it will cost Accepted requirements arrive from intake. The agent opens with Get Project Metadata, because Yodiz statuses are defined per project and per item type and this is the only place a valid code can be read, then holds those codes for the whole run. List Project Users resolves owners into the identifiers the write operations expect. Search Items reads back everything already imported in one call, so a rerun does not duplicate the backlog. Then the agent counts: how many stories, how many task batches, how many requests in total, against what the account has left today. It posts that number rather than starting, and once approved it writes with Create User Story and Create Tasks, sending a story's whole task list in one request instead of a call per line. ### Defects that arrive with the project's own vocabulary already applied A failing build in [GitHub](https://flowrunner.ai/integrations/github) or an escalation from support becomes a Yodiz issue. The agent reads the project's severity and status vocabulary from the metadata it already loaded, so Create Issue writes values the project actually defines rather than values that worked on a different project. It sets a responsible person rather than an owner, because issues are the one item type where Yodiz names that field differently. Add Attachment carries the log file across from a URL. As work happens, Log Issue Effort records time against the date it was spent, and a digest of new and closed issues posts to [Slack](https://flowrunner.ai/integrations/slack). ### Sprint reporting that fits inside the budget Reporting on a sprint the naive way means reading the stories, then the tasks under each, then the issues under each, which on a real sprint is more calls than the account can afford. The agent does it in three. List Sprint User Stories returns the sprint's stories, List User Story Subitems returns the tasks and issues beneath all of them in a single request, and List Sprints supplies the dates, trimmed by the agent because that listing returns more rows than it is asked for. The assembled burndown appends to [Google Sheets](https://flowrunner.ai/integrations/google-sheets) and the summary posts to the team channel. Because Yodiz has no webhooks, this runs on a schedule chosen to leave room for everything else the account needs that day. ## Human-in-Loop Highlight Yodiz limits an account to 400 API requests a day and 30 a minute, which is small enough to change how a flow should be written and, more to the point, small enough that one agent can take the whole account offline for everyone else. A backlog import of a few hundred stories with their task lists is not just slow, it is the day's budget. Once it is spent, the sprint report does not run, the defect intake stops, and the connection to a person's own dashboard starts failing, until midnight. There is no way to buy the allowance back, and even the connection check spends two of it. So a bulk write agent treats the budget as the shared resource it is. It calculates the cost, then asks in the delivery channel: "Importing the accepted backlog is 218 stories and 61 task batches, roughly 290 requests. The account has about 340 left today, and the sprint report and defect intake still need around 80 between them. Run the full import now and skip today's report, import the 90 stories tagged for this sprint only, or hold the whole thing until the counter resets?" A person picks, because a person knows which of those flows somebody is waiting on. The agent then executes exactly that and, since an unknown route in this API answers with a success and an empty body rather than an error, it reads the created stories back rather than trusting the count it got. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 45 actions ### Connection and Projects 6 - **Verify Credentials** Checks the connection by signing in and reading the projects the credentials can see, confirming all three settings at once. It spends two of the account's daily requests, so it belongs in setup rather than in a loop. - **List Projects** Returns the projects the credentials can reach with their titles, labels, owners and workflow schemes. Usually the first call in a flow, since everything else is scoped to a project. - **List Project Users** Returns the people on a project with the identifiers that the owner, responsible and follower fields expect everywhere else in this connector. - **List Components** Returns a project's components, the areas of the product a story or an issue can be filed under. - **Get Project Metadata** Returns the vocabularies one project uses for one kind of item: its statuses, its people, and whichever of severities, priorities and estimation methods that kind has. Statuses are per project and per item type, so this is the only place a valid code can be read. - **List Custom Fields** Returns the custom fields a project defines for one kind of item. A project with none answers with an empty list rather than an error. ### Backlog and Search 2 - **List Backlog** Returns a project's backlog as its user stories in priority order. A filter is required, and it selects everything, unscheduled work, scheduled work or completed work. - **Search Items** Returns items of one kind by identifier across one or more projects, which is how a workflow reads a batch of known records without a request each. ### Epics 6 - **List Epics** Returns a project's epics, the largest unit of work in Yodiz, which hold user stories beneath them. - **Get Epic** Returns one epic with its plan estimate, status and owner. - **Create Epic** Creates an epic on a project. The status code has to come from the project's own vocabulary, and tags are matched by title, so a tag that does not exist yet is created. - **Update Epic** Updates an epic's title, description, status, owner or tags. Only the properties supplied change. - **Delete Epic** Deletes an epic. Worth reading back afterwards, because an unknown route in this API answers with a success rather than an error. - **List Epic User Stories** Returns the user stories filed under one epic. An epic with none answers with an empty list. ### User Stories 10 - **List User Stories** Returns a project's user stories with a paging block, so a workflow can walk a whole project. Ask for the fields you need, because estimates and sprint links are absent from the default set. - **Get User Story** Returns one user story with its estimate, status, epic, release, sprint and tags. - **Create User Story** Creates a user story on a project. Story points are free text rather than a number, because Yodiz supports point scales that are not numeric. - **Update User Story** Updates a user story. Only the properties supplied change. - **Delete User Story** Deletes a user story and the tasks beneath it. The cascade is the reason a deletion sweep here is reviewed before it runs. - **List User Story Tasks** Returns the tasks beneath one user story. - **List User Story Issues** Returns the issues linked to one user story. - **List User Story Subitems** Returns the tasks and issues beneath several user stories in one request, which is how a whole sprint's detail is read without a call per story. - **List Sprint User Stories** Returns the user stories scheduled into one sprint. - **List Release User Stories** Returns the user stories scheduled into one release. ### Issues 8 - **List Issues** Returns a project's issues with a paging block. An issue's owner is called responsible here, which is the one place Yodiz's vocabulary differs between item kinds. - **Get Issue** Returns one issue with its severity, status, release, sprint and effort figures. - **Create Issue** Creates an issue on a project. Severity and status both come from the project's own vocabulary, and high priority is a separate flag from the priority scale. - **Update Issue** Updates an issue. Only the properties supplied change. - **Delete Issue** Deletes an issue. - **Log Issue Effort** Records effort spent on an issue against a date. Both the amount and the date are required. - **List Sprint Issues** Returns the issues scheduled into one sprint. - **List Release Issues** Returns the issues scheduled into one release. ### Tasks 7 - **Get Task** Returns one task with its effort figures, owner and status. - **Get Project Task** Returns one task read through its project, which also reports the project title and label alongside it. - **Create Task** Creates a task beneath a user story. A task always belongs to a story in Yodiz, so there is no way to create one against a project directly. - **Create Tasks** Creates several tasks beneath one user story in a single request, which is how a checklist becomes a task list without a call per line. - **Update Task** Updates a task. Only the properties supplied change. - **Delete Task** Deletes a task. - **Log Task Effort** Records effort spent on a task against a date. ### Sprints and Releases 2 - **List Sprints** Returns a project's sprints with their dates, status, type and owner. This listing ignores the row limit, so a workflow expecting a small page trims the result itself. - **List Releases** Returns a project's releases with their dates, status and owner. A release groups work across sprints, which is why a story or an issue can carry both. ### Comments and Attachments 4 - **List Comments** Returns the comments on one item with their authors and creation times. - **List Attachments** Returns the files attached to one item, each with its name, type and a download link. - **Add Attachment** Uploads a file from a URL and attaches it to an item. Yodiz caps attachments per item collectively, so a large file on an item that already has some is refused. - **Download Attachment** Downloads one of an item's attachments into FlowRunner file storage and returns its URL. The attachment is found by name, because Yodiz gives attachments no identifier of their own. ## Frequently Asked Questions ### What can FlowRunner do with Yodiz? FlowRunner agents can run Verify Credentials, List Projects, and List Project Users in Yodiz, plus 42 more actions. ### Does connecting Yodiz to FlowRunner require OAuth? No. Yodiz connects to FlowRunner with session-based authentication, no OAuth flow required. ### Can Yodiz trigger a FlowRunner workflow automatically? Yodiz doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Yodiz?** This integration exposes Yodiz to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/yodiz. Site index: https://flowrunner.ai/llms.txt