Chirio
Get Started
Introduction
Quickstart
How Chirio works
Authentication
Platforms
Overview
Instagram
Threads
X
LinkedIn
Supa Hub
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
Supa Hub
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

Roadmap

What is not built yet, and what is deliberately never going to be.
Updated 1mo ago
Where Chirio is heading. Dates are intent, not commitment.

Not in the product today

Known gaps, listed so nobody builds around a feature that does not exist:
  • Automatic retry and backoff for transient platform failures. Rate limits and media_processing_timeout currently surface to you as a failed target to retry yourself. Scheduled posts are the exception — a dispatch that fails on infrastructure is retried, though a platform's refusal is still final.
  • A normalised error taxonomy. A rate limit currently reads differently depending on which network produced it — the platform's own message passes through.
  • Engagement triggers. "Repost once it passes 500 likes" is something you assemble today from metrics and a repost call. Chirio runs no rules engine of its own yet.
  • Reposts beyond X. X is the only network with a repost implementation; the others report unsupported until their contracts are verified.
  • Annual billing. Monthly only for now.

Shipped since this page was first written

  • Engagement metrics — GET /api/v1/posts/:id/metrics, live per target.
  • An OpenAPI 3.1 spec for /api/v1, served at /openapi.yaml.
  • Scheduling — see the reversal below.

Coming

Developer experience. Official client libraries and richer examples than raw fetch. More networks. Ranked by what customers actually ask for rather than novelty — TikTok, Bluesky and YouTube Shorts are the current candidates. Adding one does not change any existing integration: a new platform value, the same endpoints. Analytics ingestion, so you can sync per-post performance back into your own product instead of polling and storing it yourself.

One reversal: scheduling

This page used to list scheduling as permanently out of scope, on the reasoning that a scheduler is one cron away on the caller's side. That held while there was one caller. It stopped holding once there were several: a self-hosted instance cannot lean on another product's cron, and a desktop app is not running at 09:00 to fire one. So Chirio owns the clock now. Send publishAt and a dispatcher sends the post when its time comes — see Scheduling a post.

Permanently out of scope

Not "later" — never, because they belong in whatever you build on top:
Why
**Media hosting**Storage, CDN, scanning and retention are their own product
**Outbound webhooks**Poll `GET /api/v1/posts/:id` for targets still settling
**Analytics dashboards**Ingestion may land; the UI on top of it will not

Requests

If something here matters to your integration — or something missing from it does — say so. What customers ask for is what moves up this list.