# Integrate social posting into your app
URL: https://skedcast.com/developers/guides/integrate-social-media-apis-into-your-app

Adding social posting to your app means answering four design decisions: how users connect accounts, who stores the resulting tokens, how scheduling is represented, and how your app finds out what happened. Building on an existing API answers all four for you. Here is what each decision involves.

## 1. The connect flow
Your end users need to authorize their own social accounts without handing you a password. Connect links solve this. Your app calls `POST /v1/clients/{id}/connect-invites` (the `accounts.connect` scope), gets back a URL, and sends it to the end user. They authorize each platform on a SkedCast-hosted page and never see a SkedCast login. SkedCast's own agency customers use the same mechanism to onboard their clients.

## Create a connect link for the platforms your app needs.
```bash
curl -X POST https://api.skedcast.com/v1/clients/<clientId>/connect-invites \
  -H "Authorization: Bearer sked_live_YOUR_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{ "platforms": ["instagram", "tiktok"], "expiresInHours": 72 }'
```

## 2. Token storage
Most teams underestimate this part: OAuth tokens per platform, refresh logic, and reauth handling when a user revokes access. When you build on a posting API, you never see or store a platform access token. SkedCast holds them (encrypted at rest) and you address accounts by SkedCast's own account id.

## 3. Representing a scheduled post in your own data model
Store the SkedCast post id (and, once published, each target's `externalId` and `permalink`) alongside your own domain object, such as a campaign, a listing or a drop. Treat the compose call as the write and the webhook (or a poll) as the confirmation. A `201` from POST /v1/posts confirms the post was accepted and validated, not that it has published.

## 4. Finding out what happened
Subscribe your backend to `target.published`, `target.failed` and `media.ready`, and update your own record when they arrive. This is far cheaper than polling every post you've created. See the webhooks guide for the event catalog and signature verification.

## Build it yourself or use SkedCast
Area | Build every platform integration yourself | Integrate a unified API
OAuth per platform | You build and maintain 11 | None, handled for you
Token refresh and reauth | Your responsibility | Handled. You get an `account.reauth_required` event
Media processing per platform | Your responsibility | Handled for you
Ongoing platform API changes | You track 11 changelogs | One vendor tracks them

## FAQ
**Q: Do my end users need their own SkedCast account?**
A: No. Connect links let them authorize platforms on a SkedCast-hosted page without creating a SkedCast login. Your app is the only thing they see apart from that one page.

**Q: Can I white-label this so it looks like my own product?**
A: The API and the connect link work from your own UI. You control everything your end users see except the hosted connect page itself. See the API reference for the account and post data you can show in your own interface.