Skip to main content
Blocking is bi-directional: the current user can see the accounts they have blocked, and — separately — the accounts that have blocked them. Use the blocking-user APIs to read the reverse direction: the users who have blocked the current user.
This is the directional inverse of Manage Blocked Users. “Blocked users” are accounts the current user blocked; “blocking users” are accounts that blocked the current user.
There are two read patterns:
APIBest forReturns
getBlockingUsers()A live, self-updating listLive collection of Amity.User
getAllBlockingUsers()A one-shot list for local decisionsAmity.User[]
The blocking-user APIs are available on TypeScript, iOS, and Android. They are not available in the current Flutter SDK.

Get Blocking Users

Observe the users who have blocked the current user as a live collection. Unlike getBlockedUsers(), this observer takes only a callback — there are no query parameters. Page through results with the onNextPage / hasNextPage values from the callback.
import { UserRepository } from '@amityco/ts-sdk';

let loadMoreBlockingUsers: (() => void) | undefined;

const unsubscribe = UserRepository.getBlockingUsers(
  ({ data: users, onNextPage, hasNextPage, loading, error }) => {
    if (error) {
      handleError(error);
      return;
    }

    if (!loading && users) {
      renderResults(users);
    }

    loadMoreBlockingUsers = hasNextPage ? onNextPage : undefined;
  },
);

// Stop observing when the screen is destroyed.
unsubscribe();

Get All Blocking Users

Use getAllBlockingUsers() when your app needs a one-shot list instead of a live collection — for example, to filter content or hide interactions locally. It returns up to 100 users and uses a short SDK-side cache. Call it again when you need a fresh snapshot.
import { UserRepository } from '@amityco/ts-sdk';

const blockingUsers = await UserRepository.getAllBlockingUsers();
const blockingUserIds = new Set(blockingUsers.map((user) => user.userId));
The SDK already filters content in both block directions. Use these lists for product surfaces — such as hiding a “message” or “follow” action — rather than to re-implement content filtering the SDK performs for you.

Hide Blocked Users from Feeds

Turn on excludeBlockUserPosts in a post query to drop any post authored by or mentioning a user in either block direction — people the current user blocked, and people who blocked them. Mentions are included because a blocked user can appear in a post only as a tagged participant. The SDK applies the filter on-device after fetching and re-applies it automatically whenever the block list changes.
import { PostRepository } from '@amityco/ts-sdk';

const unsubscribe = PostRepository.getPosts(
  {
    targetId: 'community-123',
    targetType: 'community',
    sortBy: 'lastCreated',
    excludeBlockUserPosts: true,
  },
  ({ data: posts }) => {
    // posts are already filtered for you
  },
);
Because filtering happens on-device after fetching, a page can return fewer items than the page size (a 20-item page that drops 3 matches shows 17). There is no automatic top-up — keep paging if you need to fill the screen.

Hide Blocked Users from Comments

excludeBlockUserComments does the same for comment threads: comments authored by a user in either block direction are dropped before you see them. Because each device filters against its own block list, a user’s comments disappear for the people who blocked them — and vice versa — with no coordination needed.
import { CommentRepository } from '@amityco/ts-sdk';

const unsubscribe = CommentRepository.getComments(
  {
    referenceId: 'post-123',
    referenceType: 'post',
    sortBy: 'lastCreated',
    excludeBlockUserComments: true,
  },
  ({ data: comments }) => {
    // comments are already filtered for you
  },
);
The same short-page behavior applies — filtered comment pages can also come back shorter than the requested page size.

Keep Block State Live

Block and unblock events arrive in real time by default through the managed BLOCK auto-subscription. Every block-aware surface — getBlockingUsers(), getBlockedUsers(), and any feed or comment query using the exclude flags above — refreshes on its own when someone blocks or unblocks the current user. No polling, no manual reload. You only need to touch this if you want to turn it off — for example, to manage a tight budget of real-time subscriptions. A missed event never breaks anything: the next fetch reconciles with the server.
import { Client, AmityAutoSubscription } from '@amityco/ts-sdk';

Client.disableAutoSubscriptions([AmityAutoSubscription.BLOCK]); // stop receiving
Client.enableAutoSubscriptions([AmityAutoSubscription.BLOCK]);  // turn back on
Most apps leave this on and real-time “just works.” Turning it off only makes sense if you are managing a limited number of real-time subscriptions.

Recipe: Anonymize Blocked Users in a Reaction List

Reactions are out of scope for the automatic block filters. To keep everyone in a reaction list but show people in a block relationship as “Anonymous”, combine both block lists client-side and relabel matching reactors. (To hide them instead, filter those reactions out rather than relabeling.)
import { ReactionRepository, UserRepository } from '@amityco/ts-sdk';

const blockRel = [
  ...(await UserRepository.getAllBlockedUsers()),
  ...(await UserRepository.getAllBlockingUsers()),
];

ReactionRepository.getReactions(
  { referenceType: 'post', referenceId: 'post-123' },
  ({ data: reactors, loading }) => {
    if (loading) return;
    // Keep every row; relabel the ones in a block relationship.
    render(
      reactors.map((r) =>
        blockRel.some((u) => u.userId === r.userId)
          ? { ...r, displayName: 'Anonymous' }
          : r,
      ),
    );
  },
);
This is a client-side pattern, not an SDK feature — it is built from getAllBlockedUsers() + getAllBlockingUsers() plus your existing reaction query.

Manage Blocked Users

Query accounts the current user blocked.

Block & Unblock User

Change blocked status.

User Relationship

Follow, unfollow, and blocking overview.