Choose managed or customer-provided OAuth apps
Decide whether users connect through App9-managed credentials or a provider app owned by your organization.
Managed provider apps reduce setup time during onboarding and provider review, while customer-provided apps preserve your OAuth branding and credential ownership. Both connection modes use the same App9 Post account and publishing resources after authorization.
What this means in practice
Managed provider apps reduce setup time during onboarding and provider review, while customer-provided apps preserve your OAuth branding and credential ownership. Both connection modes use the same App9 Post account and publishing resources after authorization.
Use the documented brand and account boundaries consistently across the scheduler, REST API, SDK, MCP tools, SSE consumers, and webhooks. That makes the same social operation explainable to an operator and reproducible by an integration.
Implementation checklist
Use managed credentials for evaluation when the provider and requested capability are certified.
Choose customer-provided credentials when OAuth must display your brand or your provider agreement requires ownership.
Register the exact environment-specific redirect URI shown by App9 Post.
Keep client secrets server-side and submit them only through the protected credential-management interface.
Test refresh, revocation, reconnect, and provider-review outcomes before production launch.
Example request
This example uses a server-side API key and an explicit brand selection. Replace placeholder values and keep credentials out of browser bundles, client logs, and source control.
curl --request POST \
--url 'https://postapi.app9.co/v1/provider-apps' \
--header 'Authorization: Bearer APP9_POST_API_KEY' \
--header 'X-App9-Post-Brand: BRAND_ID' \
--header 'Content-Type: application/json' \
--data '{
"provider": "linkedin",
"mode": "byo",
"client_id": "YOUR_CLIENT_ID",
"client_secret": "YOUR_CLIENT_SECRET",
"redirect_uri": "https://postapi.app9.co/v1/social-accounts/oauth/callback"
}'Operational details
Provider approval requirements are controlled by each network and can change independently of App9 Post.
A provider app is brand-scoped and can be selected when creating an account authorization URL.
Switching credential ownership does not make provider policies or rate limits disappear.
Common mistakes to avoid
- Do not publish a client secret in browser code or documentation screenshots.
- Do not share a development provider app with production unless the provider explicitly supports that lifecycle.
- Do not claim white-label OAuth until the customer's provider app has completed any required review.