Chirio
Get Started
Introduction
Quickstart
How Chirio works
Authentication
Platforms
Overview
Instagram
Threads
X
LinkedIn
Guides
Connect accounts
Publish a post
Media requirements
Carousels
First comments
Idempotency and retries
Account lifecycle
Revocation and deletion
The dashboard
Billing
Plans
Metering
Quotas
Api Reference
Overview
Accounts
Posts
Errors
Changelog
Roadmap
TrademarkTrademark
Ctrl k
Search...
Sign up
Chirio
Get Started
Introduction
Quickstart
How Chirio works
Authentication
Platforms
Overview
Instagram
Threads
X
LinkedIn
Guides
Connect accounts
Publish a post
Media requirements
Carousels
First comments
Idempotency and retries
Account lifecycle
Revocation and deletion
The dashboard
Billing
Plans
Metering
Quotas
Api Reference
Overview
Accounts
Posts
Errors
Changelog
Roadmap
TrademarkTrademark© Dopler. All rights reserved.
Built with Aveiro
Get Started

Introduction

What Chirio is, the objects it works with, and the shape of every request.
Updated 3d ago
Quickstart
Chirio is a social publishing API. It does one job: take a piece of content and put it on several social networks, on behalf of accounts that authorised you to. The service runs at https://chirio.dev. You do not register platform apps, go through Meta's App Review, or hold any platform credentials — Chirio holds them, and your users authorise Chirio directly. It is multi-tenant by design. Each project has its own API keys, connected accounts and post history, so a product that publishes on behalf of its own users can keep one project per customer.

The objects

Object
What it is
**Project**Your tenant. Owns keys, accounts, posts and a billing plan.
**API key**`chirio_sk_...`. Authenticates every `/api/v1/*` call. Stored hashed — the raw key is shown once and never again.
**Social account**One authorable identity on one platform: an Instagram professional account, a Threads profile, an X account, a LinkedIn profile or company page.
**Post**One piece of content plus the list of targets it was sent to.
**Target**The post as it landed on one account. Carries its own `status`, `url`, `error` and comment outcome.
The distinction between a post and a target is the one worth internalising. A publish call creates one post with many targets, and those targets can disagree: Instagram publishes, LinkedIn fails on a media error, Threads is still processing a video. Chirio returns all three rather than collapsing them into a single success or failure.

The shape of a call

Every request under /api/v1 carries a bearer key: Every error comes back in the same envelope, whatever went wrong:

The two flows

Connecting is asynchronous and involves your user. You ask Chirio for an authorize URL, send the user to it, and they return to a redirect of your choosing carrying an accountId. See Connect accounts. Publishing is synchronous. One POST /api/v1/posts fans out to every target, waits for each platform, and returns the outcomes. Video can push that to minutes, which is why idempotency keys exist. See Publish a post.

What Chirio does not do

Deliberately out of scope, so you know what you still own:
  • Media hosting. Every mediaItems[].url must be a public URL the platforms can fetch.
  • Scheduling. You own the clock; Chirio publishes when you call it.
  • Outbound webhooks. Poll GET /api/v1/posts/:id for targets that are still settling.

Next

  • How Chirio works — what happens during a publish
  • Quickstart — first published post in a few minutes
  • Authentication — API keys
  • API reference — every endpoint
curl https://chirio.dev/api/v1/accounts \
  -H "Authorization: Bearer chirio_sk_..."
{ "error": { "code": "invalid_request", "message": "..." } }