[API] subscriptions user.github_username is null.

[razonyang]

Dear Polar Team,

I'am using sandbox API for testing my integration, and I found that the subscriber's GitHub username is null.

I confirmed that the subscriber has connected to GitHub (log in via GitHub).

The subscriptions API returns null.

[frankie567]

Hi @razonyang 👋

Unfortunately, that's expected. But first a bit of rationale:

Recently, we changed how we handle users vs customers. Before, everybody (sellers and customers) was a User on Polar. This was causing lot of limitations and weird UX issues (like the need to create a Polar account to access purchases).

Now, there are Users (the sellers on Polar) and Customers (people who bought something from an Organization). The last point is crucial: each Organization has its own set of Customers, with their own ID, subscriptions and benefits. It means that, from an API point of view, an Organization doesn't interact with Users, only with the Customers it owns.

This pattern allowed us to unlock lot of interesting things, like Customer Portal, Customer metadata, and lots of good things for the future.

You can read all the details about it here: #4543

---

Now, to your issue. The user property you see in the API is only provided here for backward compatibility, but should be considered as deprecated. The information you need will be available directly on customer. Unfortunately, it means you no longer have access to the GitHub username, since it's handled differently now.

That said, if you have an interesting use-case requiring access to the GitHub username, we would be happy to tweak the API so this data can be surfaced.

[razonyang]

Thank you for your prompt reply.

if you have an interesting use-case requiring access to the GitHub username.

I'm using Supabase for authentication, which allow logging in via GitHub etc. However, it doesn't support Polar or custom OAuth2 providers yet. So I'm trying to verify if a logged in GitHub user is a subscriber on Polar, and then decide whether to show or hide the premium posts, ADs and so on.

The ideal approach is to log in with Polar, so that I can obtain Polar user information. I will try to implement Polar OAuth2 from scratch without the Supabase backend.

Thanks again.

[frankie567]

Ok I see. Implementing our OAuth2 authentication likely won't solve your issue.

Actually, I think your use-case would be better served using our webhooks and customer metadata. Basically:

• If not already, add a Custom benefit on your Polar Product (e.g. "Access to my service"). This benefit has an ID, say YOUR_POLAR_BENEFIT_ID
• You have your users authenticated with Supabase, that's great and should stay that way. Each of your user have an ID, say SUPABASE_USER_1.
• When a user wants to subscribe to your service, create a Checkout Session with the Polar API. The key thing is to set your ID SUPABASE_USER_1 in customer_metadata. Basically, it'll look like this:

{
    "payment_processor": "stripe",
    "product_id": "YOUR_POLAR_PRODUCT_ID",
    "customer_metadata": {
        "user_id": "SUPABASE_USER_1"
    },
    "customer_email": "[email protected]" // You can prefill with your user's email
}

• Redirect the user to the Checkout Session URL, where they'll be able to subscribe to your service💰
• After that, a Customer will be created on Polar, and they'll have {"user_id": "SUPABASE_USER_1"} in metadata.

---

• In your backend, listen for Polar webhooks. In particular, you'll be interested in benefit_grant.created event. In this event, you'll be able to catch two things:
  1. The benefit_id
  2. The customer_id (say, POLAR_CUSTOMER_ID)
• If benefit_id === 'YOUR_POLAR_BENEFIT_ID', you know your "Access to my service" benefit has been granted.
• Now, query the Polar API to get the Customer POLAR_CUSTOMER_ID. Look for metadata.user_id.
• Success! You can now, in your database, save that SUPABASE_USER_1 has access to your service.

Do the same thing for benefit_grant.revoked to handle the case when a user unsubscribes.

[frankie567]

Side note: I'll tweak the webhook so customer is directly embedded in the event, avoiding the need to get the Customer manually from the API ;)

[razonyang]

Thank you for your valuable professional advice. I will read those documents and figure out how to implement them.

[razonyang]

Hi, I'm thinking about if there is a subscription field to match userinfo's sub?

I've checked the customer_id, customer.id, user_id and user.id, however none of them match the userinfo's sub (same user, email).

It would be great and much easier if there was a field to match the userinfo' sub, so I don't need to checkout sessions, just need to redirect users to preset plans with URLs (just like GitHub sponsors page with tiers).