Skip to main content
Question

Feature Request: Include lookup_key in all entitlement objects (e.g. in /customers/{id} response)

  • August 21, 2025
  • 3 replies
  • 43 views
F
Forum|alt.badge.img

I’ve been working with the API and noticed that in several endpoints where active_entitlements or similar objects are returned in a lightweight format, we only get the internal entitlement_id, like this:
 

{
  "entitlement_id": "entl498b7a7b44",
  "expires_at": 1755783769000,
  "object": "customer.active_entitlement"
}

However, it would be extremely helpful if the lookup_key was included as well in these responses.

For example, in:
GET /v2/projects/{project_id}/customers/{customer_id}
GET /v2/projects/{project_id}/customers/{customer_id}/active_entitlements

We only get the internal ID, and in order to know which entitlement this refers to (e.g. "Pro", "Premium", etc.), we have to make an additional API call to:
GET /v2/projects/{project_id}/entitlements/{entitlement_id}
 

This adds unnecessary complexity and overhead, especially when managing entitlements for multiple users at scale.

Would it be possible to include the lookup_key directly in all entitlement summaries across the API?

It would make integrations much smoother and reduce the number of API calls needed for basic entitlement resolution.

This post has been closed for comments

3 replies

jeffrey_bunn
RevenueCat Staff
Forum|alt.badge.img+6
  • jeffrey_bunn
  • RevenueCat Staff
  • August 25, 2025

Hi ​@fábio-ferreira-925142, thank you for the feedback! Yes, this would be a clear improvement. I have shared this with our team responsible for the V2 API. I don’t have a timeline for when this information will be included, but our team is aware of the inconvenience. 

For now, you could create an internal mapping in your backend of entitlement_id → lookup_key, but I understand this could get quite involved if you’re managing this for many customers. 

Thanks again for sharing this!

F
F
Forum|alt.badge.img

Hi ​@fábio-ferreira-925142, thank you for the feedback! Yes, this would be a clear improvement. I have shared this with our team responsible for the V2 API. I don’t have a timeline for when this information will be included, but our team is aware of the inconvenience. 

For now, you could create an internal mapping in your backend of entitlement_id → lookup_key, but I understand this could get quite involved if you’re managing this for many customers. 

Thanks again for sharing this!

Thank you for your reply. Yes, I can manage that on my side, but at the moment the V2 API requires too many calls to get the same information we could retrieve directly in V1.

Also, you really need to standardize the naming. For example, in webhooks we receive:

product_id => com.appname.product

But in the API, product_id refers to your internal ID, and we need to make an extra call to fetch the details where com.appname.product is now under the store_identifier attribute.

This inconsistency makes things unnecessarily complicated. Honestly, I can’t understand how such a confusing design decision was made.

jeffrey_bunn
RevenueCat Staff
Forum|alt.badge.img+6
  • jeffrey_bunn
  • RevenueCat Staff
  • August 29, 2025

​@fábio-ferreira-925142 100%, thank you again. All this is being shared with our product team. Really sorry for the additional work you’re having to do here.

Terms & ConditionsCookie settingsAccessibility statement