Posttar API

Long-running calls

Two operations answer 202 and finish in the background.

Two operations start heavy work and answer before it finishes: creating a post, in any of the six formats, and publishing. They answer 202, not 200, because Posttar does not pretend the work is done. The resource comes back in its real state, and you fetch the outcome later with a GET.

OperationMedianp99
POST /posts (carrossel)43 s87 s
POST /posts (leia_a_legenda)40 to 70 s in the common case
POST /posts (audio_animado)around 1 minute
POST /posts (narrated_photos)around 2 minutes
POST /posts/:id/publish38 s61 s

Measured in production. While a post is not finished, status stays queued or generating. When it finishes it becomes draft, ready for review, or failed. Poll GET /posts/:id until it leaves those two states.

There is no outcome webhook in this version. Polling is the only way to learn that a long call finished.

Create a post and wait for it

The whole sequence, in order. Copy this block if you are handing the flow to an agent.

  1. 1

    Start the creation. Answers 202.

    curl -X POST -H "Authorization: Bearer $POSTTAR_KEY" -H "Content-Type: application/json" \
      -d '{"projectId":"c85848ba-...","theme":"three signs your niche is too broad"}' \
      "https://api.posttar.com/v1/posts"
    { "postId": "dd8d142c-4cba-4ea6-9088-e948ac347f56", "format": "carrossel", "state": "generating", "remainingCredits": 5 }
  2. 2

    Poll until status leaves queued and generating.

    curl -H "Authorization: Bearer $POSTTAR_KEY" \
      "https://api.posttar.com/v1/posts/dd8d142c-4cba-4ea6-9088-e948ac347f56"
    {
      "id": "dd8d142c-4cba-4ea6-9088-e948ac347f56",
      "status": "generating",
      "projectId": "c85848ba-2881-4a2e-9bdd-841b26d07359",
      "workspaceId": "2bd5c04d-1dd4-456e-8704-9d7b84703fd0",
      "scheduledFor": null,
      "textContent": null,
      "mediaUrls": []
    }

Creating answers state, reading answers status. They are two different fields of two different shapes: state only ever says "generating", because that is all the creation call knows, while status carries the real lifecycle (queued, generating, draft, scheduled, published, failed). Read what the specific call returns instead of assuming similar fields share values.