--- title: "CherryIN Integration" description: "Reach CherryIN's multi-provider model catalog through one OpenAI-compatible connection. Agents switch models without rewriting the flow or adding another credential." url: https://flowrunner.ai/integrations/cherryin date_modified: 2026-08-07T17:20:23-07:00 --- # CherryIN [AI](https://flowrunner.ai/integrations/category/ai-llms) Reach CherryIN's multi-provider model catalog through one OpenAI-compatible connection. Agents switch models without rewriting the flow or adding another credential. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 2 actions · API key · available [CherryIN website](https://cherryin.net/) · [Platform Documentation](https://open.cherryin.net) · Capability data verified 2026-08-04 1. A scheduled check runs against the CherryIN model picker each morning 2. Agent reads the models the current key is entitled to 3. Agent compares that list against the model IDs referenced by live customer-facing flows 4. Agent confirms which references still resolve and which have dropped off the entitlement 5. Agent posts the affected flows and the models that disappeared 6. The flow owner names the replacement model rather than letting the agent pick one ## What This Integration Enables CherryIN is narrow on purpose, and the narrowness is the point. It exposes two operations, and both send text to a model. What it actually sells is the account underneath: one key, one plan, one invoice, and access to Claude, Gemini, GPT, DeepSeek, and other providers behind a single OpenAI-compatible interface. Model IDs take a `provider/model` form, so the vendor is visible in the value your flow carries rather than buried in a connection setting. The detail worth knowing before you build on it is that CherryIN's model picker reads the models **your key is entitled to**, not a global catalog. That is a better default than a marketing list, because the picker cannot offer a model the plan does not cover. It also means the roster moves when your plan moves. Build for that and the [connectors](https://flowrunner.ai/concepts/connectors) in your flows stay honest about what they can call. Ignore it and you find out through a failed request in a customer-facing path. One more thing that will bite if nobody tells you: OpenAI's GPT-5.x series does not accept chat completions requests. Those models go through Create Model Response, which takes a plain text input instead of a messages array. Same key, same account, different action. ### Without FlowRunner **A credential per provider**: Claude, Gemini, GPT, and DeepSeek each arrive with their own key, plan, and invoice **Entitlement is invisible**: Nobody knows which models a given plan actually covers until a request fails **Provider swaps touch the flow**: Moving a step to another vendor means changing how the step is built, not just what it names ### With FlowRunner **One entitlement to reason about**: The model picker reflects what this key can actually call today **Provider swaps are a field change**: The model ID is a value in the step, and the surrounding flow does not move **One billing relationship**: Spend across providers arrives on one account instead of four ## Use Case Scenarios ### Provider consolidation without a rebuild A team has four flows, each calling a different vendor directly, each with its own key sitting in a different place. Migrating them to CherryIN replaces four credentials with one and leaves the flow logic where it is, because the request shape is OpenAI-compatible in every case. The model ID moves from a hard-coded string in each flow to a value the flow reads, which means the next vendor change is a field edit rather than a project. ### Cost tiering inside one flow An inbound email triage flow does not need the same model for every step. The agent uses a small, cheap model to classify intent and detect language, then routes only the messages that need drafting to a stronger model, then writes the result into [HubSpot](https://flowrunner.ai/integrations/hubspot). Both calls go through Create Chat Completion against the same key. The tiering is a decision in the flow, not a second contract. ### Adopting a GPT-5.x model without breaking the existing path A summarization step is moving to a GPT-5.x model. Because that series does not accept chat completions requests, the agent branches: the new model runs through Create Model Response with a plain text input, and the previous model stays on Create Chat Completion until the new output has been checked against the old on real traffic. The team compares the two in [Notion](https://flowrunner.ai/integrations/notion) before retiring the original branch. ## Human-in-Loop Highlight The moment this connector needs a person is entitlement drift. Because the picker reflects what your key can call rather than a fixed catalog, a plan change or a roster change on CherryIN's side can remove the exact model a live flow depends on. An agent that quietly substitutes the nearest available model has just changed the voice, the refusal behavior, and the policy posture of every customer-facing message that flow produces, and nobody approved that. So the agent does not substitute. When a referenced model stops appearing in the entitled list, it holds the affected flows and asks the owner in [Slack](https://flowrunner.ai/integrations/slack): "The customer reply flow calls `anthropic/claude-sonnet-4.5`, which is no longer in this key's entitlement. Three flows are affected and are paused. Which model should replace it, or should the plan be restored?" A person names the replacement, the agent resumes, and no customer receives a message from a model that was never chosen for them. That is [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) doing the job it exists for: the agent knows the boundary of what it is allowed to decide. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via Slack Human decides Agent resumes with decision ## Agent Capabilities 2 actions ### Chat Completions 1 - **Create Chat Completion** Sends a conversation to any model your CherryIN key is entitled to, through an OpenAI-compatible interface covering Claude, Gemini, GPT, DeepSeek, and other providers. Supply a Prompt for single-turn work or a full Messages array to carry multi-turn context. This is the default path for every model except OpenAI's GPT-5.x series, which requires Create Model Response instead. ### Responses 1 - **Create Model Response** Sends a single text input to a model through the CherryIN Responses endpoint and returns its reply. This is the endpoint OpenAI's GPT-5.x series requires, since those models do not accept chat completions requests. It takes plain text rather than a messages array, so a step moving to a GPT-5.x model changes action as well as model ID. ## Frequently Asked Questions ### What can FlowRunner do with CherryIN? FlowRunner agents can run Create Chat Completion and Create Model Response in CherryIN. ### Does connecting CherryIN to FlowRunner require OAuth? No. CherryIN connects to FlowRunner with an API key, no OAuth flow required. ### Can CherryIN trigger a FlowRunner workflow automatically? CherryIN doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at CherryIN?** This integration exposes CherryIN 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/cherryin. Site index: https://flowrunner.ai/llms.txt