Hey! Loved your recent set. Are custom requests open?
", "giphyId": null, "lockedText": false, "isFree": true, "price": 0, "isMediaReady": true, "mediaCount": 0, "media": [], "isTip": false, "fromUser": { "id": 441029, "name": "JohnDoe", "username": "johndoe", "avatar": "https://public.onlyfans.com/files/avatar/user.jpg" } } } ``` ## Webhook-Sicherheit & HMAC-SHA-256-Verifizierung Um sicherzustellen, dass eingehende Payloads ausschließlich aus vertrauenswürdigen Quellen stammen und nicht manipuliert wurden, solltest du jede Anfrage verifizieren. Der [Leitfaden zu HMAC-SHA-256-Webhook-Sicherheit & -Verifizierung](https://docs.onlyfansapi.com/webhooks/protecting-your-webhooks) empfiehlt, jedem Webhook ein Signing Secret hinzuzufügen. Ist eines gesetzt, trägt jede Zustellung einen `Signature`-Header mit dem HMAC-SHA-256-Hex-Digest des rohen Anfrage-Bodys, berechnet mit dem Signing Secret dieses Webhooks als Schlüssel. Die Quell-IPs sind nicht stabil, also verifiziere die Signatur, statt IPs auf eine Allowlist zu setzen. Die Signatur allein schützt nicht vor Replays; dedupliziere stattdessen anhand des `X-OFAPI-Idempotency-Key`-Headers. ### Verifizierungs-Snippet für Node.js / Express ```javascript const crypto = require('crypto'); const express = require('express'); const app = express(); app.use(express.raw({ type: 'application/json' })); app.post('/webhook/onlyfans', (req, res) => { const signature = req.headers['signature'] || ''; const signingSecret = process.env.ONLYFANS_WEBHOOK_SECRET; const computedSignature = crypto .createHmac('sha256', signingSecret) .update(req.body) .digest('hex'); const a = Buffer.from(signature); const b = Buffer.from(computedSignature); if (a.length !== b.length || !crypto.timingSafeEqual(a, b)) { return res.status(401).send('Invalid signature'); } const event = JSON.parse(req.body.toString()); const idempotencyKey = req.headers['x-ofapi-idempotency-key']; // anhand dieses Werts deduplizieren console.log(`Received event: ${event.event} for account ${event.account_id}`); // Zuerst antworten (10 s Zeitbudget), dann asynchron verarbeiten res.status(200).json({ received: true }); }); ``` ### Verifizierungs-Snippet für Python / FastAPI ```python import hmac import hashlib import json from fastapi import FastAPI, Request, HTTPException, Header app = FastAPI() SIGNING_SECRET = "your_webhook_signing_secret" @app.post("/webhook/onlyfans") async def handle_onlyfans_webhook( request: Request, signature: str = Header(None), # Header-Name: Signature x_ofapi_idempotency_key: str = Header(None), ): body = await request.body() computed_signature = hmac.new( SIGNING_SECRET.encode(), body, hashlib.sha256 ).hexdigest() if not hmac.compare_digest(computed_signature, signature or ""): raise HTTPException(status_code=401, detail="Invalid HMAC signature") payload = json.loads(body) event_type = payload.get("event") # Anhand von x_ofapi_idempotency_key deduplizieren, dann asynchron verarbeiten return {"status": "ok", "event": event_type} ``` ## Automatisierung & No-Code-Pipelines Statt umfangreiche eigene Server-Backends zu verwalten, nutzen Growth- und Operations-Teams [OnlyFansAPI](https://onlyfansapi.com/), um Events über [native Integrationen](https://onlyfansapi.com/no-code) direkt in gängige Automatisierungsplattformen zu leiten. ### Workflow mit dem n8n Community Node Mit dem offiziellen Paket aus dem [Quickstart zur n8n-Integration von OnlyFansAPI](https://docs.onlyfansapi.com/integrations/n8n) (`@onlyfansapi/n8n-nodes-onlyfansapi`) kannst du visuelle Workflows bauen: 1. **Trigger:** Richte den OnlyFans-API-Trigger so ein, dass er auf `subscriptions.new` hört. 2. **Filter:** Leite zahlende Abonnenten (`payload.replacePairs["{PRICE}"]` ist nicht `"free"`) getrennt von denen weiter, die kostenlos einsteigen. 3. **Aktion:** Ruf einen OpenAI- oder Claude-API-Node auf, um dynamisch eine [individuelle Willkommensnachricht](/de/blog/onlyfans-willkommensnachricht-vorlagen-automatisierung) zu generieren. 4. **Ausgabe:** Nutze die Aktion „Send Message“ des `OnlyFans API`-Nodes, um den Abonnenten innerhalb von Sekunden zu begrüßen. ### Instant Triggers in Zapier Mit der [OnlyFansAPI-Zapier-App & Instant Triggers](https://docs.onlyfansapi.com/integrations/zapier) bauen auch Operatoren ohne technischen Hintergrund zuverlässige Alert-Systeme: - **Trigger:** Instant Trigger bei Chat Message PPV Purchased (`messages.ppv.unlocked`). Zapier hat keinen Trinkgeld-Trigger, leite `tips.received` daher stattdessen über einen direkten Webhook. - **Aktion 1:** Sende einen formatierten Alert in den eigenen Slack-Channel eines Creators (z. B. `#vip-revenue-alerts`). - **Aktion 2:** Trag den Customer Lifetime Value (LTV) und Trinkgeld-Einträge direkt in ein CRM in Google Sheets oder Airtable ein. ### Benachrichtigungs-Bots für Telegram & Slack Für Chat-Teams von Agenturen, die mehrere Creator betreuen, sorgen Trinkgeld-Alerts direkt in Telegram dafür, dass sich das Team nahezu in Echtzeit um wertvolle VIPs kümmert. Ruf diese Funktion in deinem `tips.received`-Handler auf, mit `payload["amountGross"]` als Betrag und `payload["user"]["name"]` als Namen des Fans: ```python import requests def send_telegram_alert(bot_token, chat_id, fan_name, tip_amount, creator_handle): message = ( f"🚨 *NEW TIP RECEIVED*\n" f"• *Creator:* @{creator_handle}\n" f"• *Fan:* {fan_name}\n" f"• *Amount:* ${tip_amount:.2f}\n" f"⚡ *Action Required:* Prioritize reply in chat." ) url = f"https://api.telegram.org/bot{bot_token}/sendMessage" requests.post(url, json={ "chat_id": chat_id, "text": message, "parse_mode": "Markdown" }) ``` ## Resilienz der Webhook-Zustellung & Retry-Architektur Creator-Accounts mit hohem Volumen erleben beim Versand von Massennachrichten oder bei Livestreams Interaktionsspitzen. Belastbare Implementierungen von Webhook-Consumern müssen strikte Zuverlässigkeitsmuster einhalten, um Datenverlust oder doppelt gesendete Nachrichten zu verhindern. Um maximale Uptime sicherzustellen, sollten Entwicklungsteams diese drei grundlegenden Muster umsetzen: 1. **Sofortige Bestätigung (`2xx`-Handshake):** Eine Zustellung gilt nur dann als erfolgreich, wenn dein Endpunkt innerhalb des Anfrage-Timeouts von 10 Sekunden (5 Sekunden für den Verbindungsaufbau) einen `2xx`-Status zurückgibt. Speichere die Payload, antworte und starte erst danach langwierige Vorgänge wie LLM-Textgenerierung oder aufwendige Bildverarbeitung. 2. **Idempotenz-Absicherung:** Die Zustellung erfolgt mindestens einmal (at-least-once), nicht genau einmal (exactly-once). Consumer müssen den Wert des `X-OFAPI-Idempotency-Key`-Headers speichern (z. B. `evt_9c1f0a4b…`), der bei jedem erneuten Versuch und jeder manuellen erneuten Zustellung desselben Events identisch bleibt, und bereits verarbeitete Events überspringen. So verhinderst du doppelte Aktionen, etwa zwei Willkommensnachrichten per DM. Flüchtige Events wie `users.typing` haben keinen Schlüssel. 3. **Erneute Versuche & Wiederherstellung:** Gibt dein Server einen Status außerhalb von 2xx zurück oder läuft er in ein Timeout, unternimmt der Dispatcher insgesamt bis zu 3 Zustellversuche: sofort, etwa 10 Sekunden nach dem ersten Fehlschlag und etwa 100 Sekunden nach dem zweiten. Danach wird die Zustellung aufgegeben (ein `404` oder `410` beendet die erneuten Versuche sofort). Zustellungsdatensätze werden 7 Tage lang aufbewahrt, und jeder davon lässt sich über den Endpunkt Redeliver Webhook Delivery erneut senden. Nach 20 aufeinanderfolgenden fehlgeschlagenen Zustellungen wird der Webhook pausiert, und Events, die während der Pause ausgelöst werden, gehen verloren: Hol die Daten für diesen Zeitraum über die API nach.