Skip to content
Schedule Social Media
SchedulersNetworksAPI changesGuidesToolsCompareFind your schedulerNews

Press Esc to close.
Deprecation Bluesky Severity: medium

AT Protocol deprecates hardcoding bsky.social and relying on default AppView proxying

Announced7 Mar 2025
EffectiveNot stated
PlatformBluesky

What changed

In its March 7, 2025 roadmap the AT Protocol team listed deprecated patterns it will start removing "more aggressively". Clients should resolve login identifiers to PDS instances instead of hardcoding bsky.social, which still proxies requests to avoid breakage and "may stop proxying in the near future". Clients should also stop relying on the reference PDS forwarding app.bsky.* calls to api.bsky.app by default and always name a service in the atproto-proxy header. The #tombstone, #handle and #migrate firehose events, replaced in 2024, will be removed from the Lexicons.

What it means

Tools that send every request to bsky.social, or call app.bsky endpoints through a PDS without an atproto-proxy header, may break when Bluesky stops the compatibility proxying it still provides.

Who is affected

Developers of Bluesky posting, scheduling, analytics and bot tools, especially older code written before federation.

What to do

Resolve each handle or DID to its PDS and send requests there, and always set the atproto-proxy header (did:web:api.bsky.app#bsky_appview for the Bluesky AppView) on proxied app.bsky calls. No removal date was given.

What this means for you

Bluesky accounts can live on many different servers. Some older apps still send everything to Bluesky's main server and count on it to pass requests along. Bluesky has warned that this courtesy may end. If it does, those older apps could stop posting or loading. Well-maintained apps already handle this; ask your app if you are not sure.

The details

  • No hardcoded bsky.social: "Client apps should resolve user login identifiers (handles or DIDs) to PDS instances, and should not hardcode the bsky.social domain for API requests." Bluesky has kept proxying such requests "to avoid breakage" and "may stop proxying in the near future." No date was given.
  • Always set atproto-proxy: the reference PDS has forwarded app.bsky.* endpoints to api.bsky.app by default. No other namespace gets this. Clients "should always specify a service in the proxy header." The Bluesky AppView service reference is did:web:api.bsky.app#bsky_appview.
  • Old firehose events: #tombstone, #handle and #migrate were replaced by #identity and #account in 2024 and will be removed from the Lexicons (the May 2025 relay post spells #migrate as #migration). See Bluesky relay software supports Sync v1.1 for the relay side.
  • Same post, other plans: Sync v1.1 (new #sync message, tooBig removed, desynchronized and throttled account statuses, com.atproto.sync.listReposByCollection), OAuth auth scopes, and a PDS web interface for account sign-up.
  • Background: Bluesky opens federation explains why accounts may not be on bsky.social.

What to do next

  • Business owners: Nothing, unless your Bluesky tool fails for accounts hosted outside Bluesky; then ask the vendor about this change.
  • Marketers and agencies: Ask your Bluesky tool vendor whether it resolves each account's own server rather than assuming bsky.social.
  • Developers: Remove hardcoded bsky.social API calls, resolve DID to PDS at login, add atproto-proxy to app.bsky requests, and drop handling for the old firehose event types.

Primary sources

Checked against the source 7 Nov 2026

Get an email when a new API change is added

Follow new entries with the RSS feed. Each platform also has its own feed, for example X or Meta.