Skip to main content
  • Community
  • Get Help
  • SDKs
  • It is recommended to call the REST API after receiving the webhook, but there is no mention of `GET / subscribers` in the RESA API v2 documentation.

Thanks for operating the best product. It has really helped me a lot.

 

Syncing Subscription Status

Webhooks are commonly used to sync a customer's subscription status across multiple systems. Because different webhook events contain unique information, we recommend calling the GET /subscribers REST API endpoint after receiving any webhook. That way, the customer's information is always in the same format and is easily synced to your database. This approach is simpler than writing custom logic to handle each webhook event, and has the added benefit of making your system more robust and scalable.

 

It is recommended to call the REST API after receiving the webhook.

 

If you follow the recommendation and refer to the latest REST API v2 documentation, the `GET/subscribers` entry is not present.

 

The v1 documentation had a `GET/subscribers` entry.

 

Does this mean that v2 cannot retrieve customer information based on user ID?

 

If I want to get customer information based on user ID, do I have to use v1?

 

(PS)
Also, Webhook authorization is recommended, but it appears to be unavailable with v1.

What are the current best practices?

Best Practices: Webhook authorization

We recommended setting an authorization header value via the RevenueCat dashboard. When set, RevenueCat will send this header in every request. Your server can use this to authenticate the webhooks from RevenueCat.

Hi,

Happy to help here.

If I want to get customer information based on user ID, do I have to use v1?

Yes, we don’t have a v2 version of that endpoint yet, so I would just call the v1 endpoint.

 

Also, Webhook authorization is recommended, but it appears to be unavailable with v1.

You actually can pass “BEARER” in the authorization header in v1 requests, it just wasn’t required:

 

The RevenueCat REST API v2 requires stating the authorization type Bearer in the Authorization header before the API key in accordance with RFC 7235. This is different to the v1 API which allowed passing just the API key as the Authorization header.

 

So I would suggest just including that in every API request for uniformity.

Thank you for your response.

You have helped me a lot.
I am considering it again.

Reply


Terms & ConditionsCookie settings