TrackPost — Dokumentation
Getting Started
1. Erstelle und bestätige genau einen Cloud-Account. 2. Wähle oder erstelle die Organisation, der die Integration gehört. 3. Lege ein Projekt für die Website, den Shop oder die Marke an, deren Daten zusammenbleiben sollen. 4. Öffne den Produkt-Workspace und prüfe die Freischaltung, bevor du Zugangsdaten kopierst oder Produktionsverkehr sendest.
Damit ist die Account-Einrichtung abgeschlossen. Alle folgenden Abschnitte sind Implementierungsanleitungen. Zugangsdaten sind immer projektgebunden; Server-Secrets gehören niemals in Browsercode, öffentliche Repositories oder clientseitige Umgebungsvariablen.
Vor dem Veröffentlichen ein Ziel verbinden
Öffne TrackPost → Verbindungen und verbinde mindestens ein Konto, das du verwenden darfst. Wähle das angezeigte Ziel im Beitrag oder API-Aufruf; TrackPost verhindert Veröffentlichungen an nicht verfügbare oder nicht autorisierte Ziele.
Publishing-Konten verbinden
Nach der Freischaltung kann jeder Nutzer die Facebook Pages, professionellen Instagram-Konten, Threads-Profile, Google-Business-Standorte, LinkedIn-Profile oder LinkedIn-Unternehmensseiten verbinden, über die er veröffentlichen darf. Der OAuth-Callback importiert geeignete Konten als stabile Connection-IDs; Anwendungen erfassen Provider-Tokens niemals selbst.
Ein persönliches LinkedIn-Ziel bleibt an die Person gebunden, die es verbunden hat. Providerverfügbarkeit und Berechtigungen werden je Verbindung geprüft.
TrackPost API-Key erstellen
Öffne TrackPost → API. Ein Organisationsinhaber oder Administrator erstellt einen benannten Key; der vollständige tp_live_-Token wird einmal angezeigt und gehört in einen serverseitigen Secret Manager. Im selben Bereich stehen der exakte Projektendpunkt sowie jede nutzbare Plattform und Connection-ID. Keys laufen ab und können widerrufen werden.
Mit post.publish veröffentlichen oder planen
Sende ein post.publish-Event per POST an den im Workspace angezeigten Endpunkt und nutze Authorization: Bearer <token>. eventId ist die stabile Idempotenz-ID der Integration. post akzeptiert Text, HTTPS-Link, HTTPS-Medien-URL oder eine Kombination; destinations enthält 1–25 Objekte mit gewählter Plattform und exakter connectionId. scheduledAt ist optional und nutzt ISO 8601.
Erlaubte Plattformwerte sind facebook, instagram, threads, google_business und linkedin. TrackPost prüft, ob jede Plattform zur gespeicherten Verbindung passt. Ein Plattformname allein veröffentlicht niemals auf allen Konten. Bestehende Integrationen dürfen das bisherige targets-String-Array weiterverwenden; eine Anfrage verwendet aber genau eines von destinations oder targets.
curl --request POST "$TRACKPOST_API_URL" \
--header "Authorization: Bearer $TRACKPOST_API_KEY" \
--header "Content-Type: application/json" \
--header "X-Request-Id: release_2030_001" \
--data '{
"eventId": "blog_release_2030_001",
"type": "post.publish",
"scheduledAt": "2030-01-15T14:00:00.000Z",
"post": {
"text": "Our new article is live.",
"linkUrl": "https://example.com/blog/article"
},
"destinations": [
{
"platform": "linkedin",
"connectionId": "CONNECTION_ID"
}
]
}'Kanalfälle und Zeitplanung
Ein Event erzeugt nach Policy-Freigabe eine Zustellung je gewähltem Ziel. Mit draft_only bleibt ein sofortiger Request Entwurf; approval_required wartet auf Freigabe. Erst geplante sofortige Requests werden verarbeitet, zukünftige scheduledAt-Werte warten auf den Scheduler. Instagram Professional benötigt passende Medien.
KI-Agenten sicher integrieren
Ein Agent darf kanalspezifische Texte und Medienreferenzen vorbereiten, sollte den finalen strukturierten post.publish-Payload aber an einen autorisierten Serverablauf übergeben. Trenne Content-Erzeugung, menschliches Review, Zielauswahl und Veröffentlichung als auditierbare Schritte. Gib API-Key oder Provider-Tokens niemals an clientseitigen Agentencode.
Freigabe und Idempotenz
Prüfe exakten Inhalt, Ziel und Policy, bevor du einen Entwurf oder freigabepflichtigen Post genehmigst. Derselbe eventId mit identischem Key und Payload liefert status=duplicate. Speichere requestId, postId und Status; erzeuge wegen eines Timeouts keine neue eventId.
Responses, Fehler und Messung
Ein neuer Plan antwortet mit HTTP 202, ein idempotenter Replay mit HTTP 200. Korrigiere 400 invalid_request, 401 invalid_token, 403 permission und 409 idempotency_conflict vor einem Retry. Beachte Retry-After bei 429 und nutze begrenztes Backoff für vorübergehende 503-Fehler.
TrackAny.Click-Parameter auf eigenen Links messen Besuche und nachgelagerte Ergebnisse, sind aber kein Beweis für eine Ansicht des Posts. Publishingstatus und Website-Attribution bleiben getrennte Signale.
Publishing-Policy für API-Keys festlegen
Ein neuer TrackPost-API-Key startet mit draft_only. post.publish erzeugt damit einen Entwurf und veröffentlicht nicht, auch wenn scheduledAt fehlt. approval_required legt passende Ziele und Formate einer berechtigten Person vor; policy_auto_publish gilt nur für ausdrücklich erlaubte Verbindungen, Formate und Kampagnen.
Ziele oder Formate außerhalb der Key-Policy werden abgelehnt. Eine Person mit Veröffentlichungsrecht kann einen Entwurf oder freigabepflichtigen Post genehmigen oder ablehnen. Die Annahme des API-Requests bestätigt noch keine Zustellung; prüfe Post und Zielstatus.
Publishing-Ziel prüfen
Verbinde ein Konto, für das du veröffentlichen darfst, und wähle die exakte Connection-ID aus TrackPost. Das Ziel muss im Workspace als nutzbar erscheinen, bevor du post.publish sendest. Bei einem persönlichen LinkedIn-Profil bleibt die Person zuständig, die es verbunden hat.
Bereite Inhalte je Kanal vor und prüfe sie vor dem Planen. Bewahre den API-Key auf dem Server auf, speichere eventId für sichere Wiederholungen und kontrolliere nach Annahme das Ergebnis jedes Ziels.