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 2 months 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.