Skip to main content
We do not infer profiles from usage patterns.

​
Background

Many crypto apps and APIs are based on addresses interacting with other addresses, but an important insight of the Feed API is that users want to follow people, not addresses. As a result, many of our API endpoints return profiles, which is an identity with one or more associated addresses.

​
How to think about profiles and addresses

Our goal is to make things as easy as possible for you. So we have a simple mental model for addresses and profiles: you send us addresses, and our API returns profiles.

​
You send us addresses

Examples:
  • To bulk-upload your internal follower network to us, send us each address and the addresses they follow.
  • When a user sees a profile and wants to follow it, use the Follow endpoint.
  • To request a user’s feed, send the user’s addresses to the Feed endpoint.

​
Our API returns profiles

Examples:
  • The discovery endpoint recommends lists of profiles.
  • When a user sends us one or more addresses to follow, we return each profile that was followed.
  • Our feed endpoint always returns the profile of the actor (along with the specific address that performed the swap).

​
Profile object

export type Profile = {
  id?: string;
  name: string;
  images?: {
    raw: string;
    sm: string;
    xs: string;
  };
  addresses: string[];
  metadata: Record<string, any>; // For storing PNL and other key-value pairs
};

​
Profile rules

We only associate addresses into a profile if there’s proven, public associations between those addresses. For now, we only associate addresses together if they’re verified under a single Farcaster account, or a user verifies their addresses in the Clicker mobile app. Right now, we support EVM addresses (returned lowercased) and Solana addresses in profiles.