Product Update: PostPeer Now Supports Bring Your Own Key

PostPeer now supports Bring Your Own Key.

This is a big one if you are building a product on top of PostPeer and you want the social connection flow to feel like yours, not ours.

Until now, most teams connected social accounts through PostPeer's managed OAuth apps. That is still the fastest path, and for many products it is the right one. You call the connect endpoint, send the user to the returned URL, PostPeer handles the OAuth callback, stores the tokens, refreshes them, and you start posting.

Bring Your Own Key keeps that same simple PostPeer flow, but lets you use your own OAuth app credentials for each platform.

So when a user connects Twitter, YouTube, LinkedIn, Pinterest, TikTok, Instagram, Facebook, or Threads, the authorization can happen under your platform app.

Why this matters

Some teams are fine using PostPeer's managed OAuth apps forever. No developer console setup. No app review work. No platform-specific OAuth maintenance.

But once PostPeer sits inside your own SaaS product, white-label product, agency platform, creator tool, or internal publishing system, you may need more control:

• Your users see your app name during authorization.
• Your OAuth consent screen can match your product and brand.
• Your platform quotas and app review history belong to you.
• Your security and compliance team can audit the exact OAuth app being used.
• Your integrations are easier to explain to enterprise customers.

That last one is underrated. If a customer asks "what app am I authorizing here?", the cleanest answer is your app.

PostPeer still does the annoying parts. We handle the callback URL, token exchange, encrypted token storage, refresh logic, posting, scheduling, and analytics. You bring the platform credentials. We run the pipes.

How it works

The flow has four steps:

1. Create an OAuth app in the platform's developer console.
2. Set the platform callback URL to PostPeer.
3. Register that app in PostPeer.
4. Pass the returned app.id when connecting an account.

That is it.

For every OAuth platform, the callback URL follows this pattern:

https://api.postpeer.dev/v1/connect/{platform}/callback

For Twitter, use:

https://api.postpeer.dev/v1/connect/twitter/callback

For LinkedIn:

https://api.postpeer.dev/v1/connect/linkedin/callback

For YouTube:

https://api.postpeer.dev/v1/connect/youtube/callback

Create the app in the platform's developer portal, paste the matching callback URL there, then copy the app's client ID and client secret.

Register the app in PostPeer

You can register the app from the dashboard or through the API.

In the dashboard, open your project, go to the apps area, and create a new OAuth app. Pick the platform, give it a name, paste the client ID and client secret, and save it.

If you prefer the API:

curl -X POST https://api.postpeer.dev/v1/apps/ \
  -H "x-access-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "platform": "twitter",
    "name": "Acme Twitter OAuth App",
    "clientId": "YOUR_PLATFORM_CLIENT_ID",
    "clientSecret": "YOUR_PLATFORM_CLIENT_SECRET"
  }'

The response includes the app you just created:

{
	"success": true,
	"app": {
		"id": "app_123",
		"platform": "twitter",
		"name": "Acme Twitter OAuth App",
		"imageUrl": null,
		"clientId": "YOUR_PLATFORM_CLIENT_ID",
		"integrationCount": 0,
		"createdAt": "2026-05-25T10:00:00.000Z",
		"updatedAt": "2026-05-25T10:00:00.000Z"
	}
}

Save the app.id. You will pass it as appId when you start the account connection flow.

The client secret is stored encrypted and never returned by the API.

Connect an account with your app

Once the app is registered, start the normal PostPeer connect flow and add appId:

curl "https://api.postpeer.dev/v1/connect/twitter?appId=app_123" \
  -H "x-access-key: YOUR_API_KEY"

PostPeer returns an authorization URL:

{
	"url": "https://twitter.com/i/oauth2/authorize?response_type=code&client_id=..."
}

Send your user to that URL. They authorize the account. The platform redirects back to PostPeer's callback. PostPeer exchanges the code for tokens, stores them, and creates the integration in your project.

If you want the user to land back inside your product after the connection completes, pass redirectUri too:

curl "https://api.postpeer.dev/v1/connect/twitter?appId=app_123&redirectUri=https://yourapp.com/settings/integrations" \
  -H "x-access-key: YOUR_API_KEY"

If you use PostPeer profiles to map connected accounts to users in your own product, pass profileId in the same request:

curl "https://api.postpeer.dev/v1/connect/twitter?appId=app_123&profileId=profile_456&redirectUri=https://yourapp.com/settings/integrations" \
  -H "x-access-key: YOUR_API_KEY"

After OAuth completes, list integrations for that profile and use the returned integration ID as accountId when posting.

curl "https://api.postpeer.dev/v1/connect/integrations?profileId=profile_456" \
  -H "x-access-key: YOUR_API_KEY"

Posting does not change

This is the part I like most about the feature: once the account is connected, the rest of PostPeer works the same way.

You still create posts through the same endpoint:

curl -X POST https://api.postpeer.dev/v1/posts \
  -H "x-access-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "platforms": [
      {
        "platform": "twitter",
        "accountId": "integration_789"
      }
    ],
    "content": "This tweet was published through our own OAuth app, with PostPeer handling the posting API."
  }'

Scheduling works the same way. Analytics work the same way. Media upload works the same way. The difference lives at the connection layer: the user authorized your app, and PostPeer runs the infrastructure behind it.

Rotating secrets

You can update an app's name, image, or client secret:

curl -X PATCH https://api.postpeer.dev/v1/apps/app_123 \
  -H "x-access-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "clientSecret": "NEW_PLATFORM_CLIENT_SECRET"
  }'

The platform and clientId cannot be changed after creation. That is intentional. Refresh tokens are tied to the client ID that issued them, and changing it would break existing integrations.

If you need to move to a different platform app, create a new app in PostPeer and reconnect the account under the new appId.

What this unlocks

Bring Your Own Key makes PostPeer a better fit for serious product integrations.

If you are building a social media scheduler, your users can connect their accounts through your brand. If you are building an AI agent that posts for customers, the OAuth app can belong to your product. If you are building an enterprise workflow, your security team can own the platform app and still avoid maintaining the posting infrastructure.

It also gives teams a nicer migration path. Start with PostPeer's managed OAuth apps while you prototype. When the product is ready and you want tighter control, create your own platform apps, register them in PostPeer, and start connecting new accounts with appId.

You do not have to rebuild posting. You do not have to rebuild scheduling. You do not have to babysit token refresh across nine platforms.

That is the point.

Use PostPeer's managed apps when you want speed. Bring your own keys when you need ownership.

The full API reference is in the Apps API docs, and the connection flow is covered in Connect Accounts.