Je gebruikers maken iets in je product en vertrekken dan om het ergens anders te posten. Die kloof dichten is een veelvoorkomende functieaanvraag, en de vorm van het werk hangt bijna volledig af van één beslissing die je aan het begin neemt.
De beslissing: van wie is het account?
Als posts naar je eigen accounts gaan, is een API-sleutel genoeg. Server-naar-server, geen toestemmingsflow, het simpelste wat er is.
Als posts naar de accounts van je gebruikers gaan, heb je OAuth nodig. Elke gebruiker autoriseert je app en jij ontvangt een scoped token gebonden aan de workspace die ze kozen.
Doe dit vanaf het begin goed. Producten die beginnen met gebruikers te vragen een API-sleutel te plakken, migreren later naar OAuth, en ondertussen hebben ze gebruikers een gewoonte aangeleerd die voor beide kanten slecht is: een langlevende credential met brede toegang plakken in een product van een derde partij.
Wat je anders zou bouwen
De reden om een publicatie-API te gebruiken in plaats van platforms rechtstreeks te integreren, is dat directe integratie een project per platform is dat nooit af is:
- Een aparte OAuth-flow per platform, met verschillende scopes en tokenlevensduren
- Een refreshtaak per platform, die stil faalt en publiceren met zich meesleurt
- Een aparte mediapijplijn per platform, met verschillende uploadmodellen
- Asynchrone publicatie bij verschillende, waar een 200 niet betekent dat het gepubliceerd is
- Een aparte rate limit per platform
- App-review bij verschillende, wat kalendertijd is die je niet controleert en die geweigerd kan worden
- Doorlopende breaking changes op het eigen schema van elk platform
Voor een SaaS waar publiceren een functie is in plaats van het product, is dat een permanente onderhoudsverplichting verbonden aan iets dat niet je onderscheidende factor is.
Wat je nog steeds bouwt
Een publicatie-API gebruiken haalt niet al het werk weg. Je hebt nog steeds nodig:
Een verbindings-UI. Ergens verbinden gebruikers hun accounts en zien de status van de verbinding.
Een zichtbare kapotte status. Verbindingen breken. Gebruikers moeten dat zien en kunnen herstellen, en het moet een status in je product zijn in plaats van een fout die je inslikt.
Compositie, in de termen van je product. De API neemt content en kanalen. Wat je gebruikers daadwerkelijk doen, en hoe dat op een post wordt gemapt, is aan jou.
Foutafhandeling. Iets zal niet lukken om te publiceren. Beslis nu of de gebruiker het van jou hoort of van de afwezigheid van een post.
Waar je op moet letten bij het kiezen
| Vereiste | Waarom |
|---|---|
| OAuth met granulaire scopes | Producten met meerdere gebruikers hebben het nodig, en smalle scopes beperken de impact |
| De specifieke platformlijst | Niet “alle grote netwerken” |
| Validatie bij het aanmaken | Zodat een bijschrift boven de limiet faalt waar jij het aan de gebruiker kunt tonen |
| Rate limits op jouw niveau | Het getal dat bepaalt of het met je meeschaalt |
| Gestructureerde fouten | Zodat je iets nuttigs kunt tonen in plaats van “publiceren mislukt” |
BulkPublish hiervoor
- Auth: OAuth 2.1 voor handelen namens de accounts van je gebruikers, API-sleutels voor je eigen
- OAuth-details: PKCE (S256) verplicht,
scopeverplicht zonder impliciete standaard, eenmalig te gebruiken autorisatiecodes, roterende refresh tokens, tokens doorgegeven alsBearer bpat_... - Scopes:
posts:read,posts:write,media:read,media:write,analytics:read,channels:read,full - Oppervlak: 59 gedocumenteerde endpoints
- Platforms: 15
Eén grens om rond te ontwerpen: OAuth-tokens reiken tot posts, schema’s, labels, media, analytics, quotagebruik en alleen-lezen kanaaldata. Accountbeheer, wat betekent team, organisaties, facturatie, credit-aankopen, API-sleutels en OAuth-app-beheer, geeft 403 terug voor elk OAuth-token inclusief full, omdat die acties een gebruiker die je app loskoppelt zouden overleven. Die hebben een API-sleutel nodig.
Beter om dat nu te weten dan het als een onverklaarde 403 in productie tegen te komen.
| Free | Pro | Business | |
|---|---|---|---|
| API-verzoeken/dag | 30 | 5.000 | 50.000 |
| API-sleutels | 1 | 5 | 10 |
De korte versie
Beslis eerst of je publiceert naar je eigen accounts of die van je gebruikers. Als het die van gebruikers zijn, gebruik dan OAuth vanaf dag één in plaats van later te migreren. Platforms rechtstreeks integreren is een permanente onderhoudsverplichting op iets dat niet je product is, en de delen die je nog steeds moet bouwen zijn de verbindings-UI, een zichtbare kapotte status, en gebruikers vertellen wanneer iets is mislukt.