FAQs

Frequently asked questions

What Garchi is, what it manages, and how your team, your application and your AI tools work with the same content.

Garchi holds the content behind your website or app — pages, articles, products, images and translations — outside your codebase. Your team edits it in the dashboard, your app reads it over a REST API, and AI clients can work with it through MCP.
Yes. Content lives separately from the frontend and you fetch it over HTTP, which is what headless means. We describe it a little more broadly because the same content is also reachable by your team in the dashboard, by AI clients through MCP, and can be published onward to social channels you connect.
No. Garchi holds the content. You build the frontend with your own framework, your developers or an AI coding tool, and point it at Garchi for what it needs.
Product and SaaS teams, agencies, freelancers and developers who would rather not keep business content in their codebase. It suits teams running several projects at once, and teams using AI coding tools that should not have to touch the app every time a headline changes.
Content in your codebase ties every copy change to a commit, a review and a deploy, and only developers can make it. Content in your own database usually means building an admin panel for it too. Garchi gives you that layer ready-made — models, an editor, permissions, restore points, media and an API — so the people who own the content can change it and your app just reads the result.
Sites get built quickly, but the content inside them keeps changing: headlines, articles, product details, images, translations. Without somewhere to put it, each of those changes means editing source code or prompting an agent to rebuild the frontend. Garchi gives that content a home outside your code. Layouts, components and functionality still live in your codebase.
A headless CMS stores and manages content separately from the frontend that displays it. You fetch the same content through an API and reuse it across websites, mobile apps, portals and anything else that can make a request.
A space is one website, product or client. It owns its own pages, items, templates, categories, assets and connected channels, and you invite collaborators to it and set what each of them can do. Nothing leaks between spaces. How many you get depends on your plan.
Yes. Each project gets its own space, all under one login. Paid plans include several, which is how most agencies run Garchi.
Yes, as long as your frontend can make an HTTP request. You create a space, model the content you want to manage, and point the relevant parts of your frontend at the Garchi API or SDK. How much work that is depends on where your content lives now — it is an integration, not a switch you flip.
No. Your app asks Garchi for content, so publishing is what makes a change live. You still deploy when the code changes — new components, new layouts, new features. If your frontend caches responses or builds statically, how fast a change shows up depends on that, which stays your call.
It is a REST API, so anything that can make an HTTP request works. There are Node.js and PHP SDKs if you prefer them, and starter kits for Next.js, Nuxt, SvelteKit and Laravel.
Pages built from reusable sections and templates, items like articles or products, categories, metadata on those items, uploaded images, video and documents, and per-language content for multilingual sites.
Flexible content records — a blog article, a product, an event, anything itemable. They start from a base schema and you extend them with metadata like authors, ratings or tags, without touching your own application's database schema.
Yes. Add the languages you need to a space, and pages and sections can hold content for each one. How many additional languages you get depends on your plan.
Usually not. Garchi is for content that gets managed and published. Users, transactions, permissions and application state belong in your own database.
Yes. Invite collaborators to a space and set what each of them can do there, so content changes do not have to go through your deployment pipeline.
Yes. The dashboard and the API are the main ways in. MCP is something you switch on if you want it — nothing requires an agent, and nothing breaks if you never connect one.
Garchi runs an MCP server. MCP is an open standard that lets an AI client call a defined set of actions on an external system instead of guessing. Connect a compatible client and it can read your content model and work with it: listing spaces, drafting pages, updating items, managing categories and metadata, and uploading or generating images.
No. Everything an agent writes through MCP is saved as a draft, and the API only serves published content, so it cannot reach your live site until you publish it. There is no MCP tool that publishes. Social posts work the same way: an agent can draft one and send it for approval, but approving, scheduling and publishing are done by a person.
Agent changes land as drafts, so you normally catch a bad one before anyone else sees it, and you can preview drafts on your own frontend first. Changes to pages, templates and items also leave restore points for 30 days, labelled with who made them, so you can put an earlier version back. That limits the damage. It is not a guarantee that nothing can ever go wrong.
Any client that speaks the Model Context Protocol and can connect to a hosted MCP server. We are not affiliated with or endorsed by those vendors — compatibility just means the client speaks MCP.
Yes, to channels you connect to a space: LinkedIn company pages and personal profiles, Instagram Business and Creator accounts, and Facebook Pages. A post is drafted, approved by a person, then published or scheduled, and Garchi records what happened on each channel. It uses images and items already in your space, so nothing gets copied between systems.
No. Garchi publishes to channels you own. There is no inbox, no comment or DM handling, no listening, no ads and no CRM. If you already use a social or marketing platform, keep it.
One credit per successful publish to one channel, so a post going to LinkedIn and Instagram uses two. Drafts, cancellations and failed attempts cost nothing. Each plan includes an allowance per space — the pricing page has the current numbers.
Through the API. Create a token in your dashboard and send it as a Bearer token in the Authorization header. Requests are subject to rate limits and to the bandwidth on your plan — the API documentation has the current numbers.
Sign up for the free Sandbox plan, create a space, add some content and generate a token. From there, call the API, use a starter kit, or connect an MCP client.

Still have a question? Get in touch or read the documentation.