#trojan_search-api-indexing

1 messages · Page 1 of 1 (latest)

slate rivetBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1381642765007585310

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

brave bobcat
#

Hi there 👋 what is the ID of the Subscription object you expected to be returned?

raven leaf
#

Hello! sub_1RUdckAcGWmAIEGMzqKpkqB3

brave bobcat
#

Out of curiosity, if you do an exact match for the following created value, does that Subscription get returned in the response?
1748652610

raven leaf
#

yes! that worked

#

is it 3 off?

#

the object showed me 07

brave bobcat
#

I'm not exactly sure yet, and I think it's something we're going to need to take a closer look at on our end.

raven leaf
#

Thanks so much. I knew I might have found something interesting

#

Can I be notified if-when its fixed?

brave bobcat
#

I'll have our bot DM you a message to create a Support case about this, and I'll work on getting this reported to the appropriate team when I have a spare moment.

One additional question, to help me understand the context here. If you have the customer.subscription.created Event, and are getting the created timestamp from it, is there a reason you can't just capture the ID of the Subscription from that Event and retrieve it directly (rather than performing a Search)?

raven leaf
#

from an event you're saying. This isn't for a fulfillment callback, its for subscription management through the billing portal. I'd rather expose loose data like a created timestamp than the direct subscription id to users, so I can attest that data to the email of the authenticated user when retrieving the subscription and creating the billing portal

brave bobcat
#

What if they have two Subscriptions with the same created timestamp, how do you know which one you should be using from the Search results?

raven leaf
#

That's a good point.. I don't allow users to check out with more than one item at a time at the moment. but I see what you mea

brave bobcat
raven leaf
#

absolutely. I've thought of alternative approaches.

  1. creating expiring public facing ids which match to the subscription ids
  2. attaching associative metadata to the subscription at creation
#

My app allows any amount of subscriptions per customer, and multiple customers per user, so getting this nailed down is critical like you guessed

#

it would be neat if there were more queryable fields in the subscriptions.search api

brave bobcat
#

Are you doing a write-then-read flow? Like are you creating a Subscription and then almost immediately doing a search for it?

I'm still not grasping why storing the ID of the Subscription doesn't work. You don't have to expose those IDs to your customers, you can just use them in your backend to track what Subscriptions belong to the customer. I may be overlooking details, but that feels like it would require the same storage capabilities as storing the creation timestamp and would allow you to more reliably retrieve the desired Subscription.

raven leaf
#

not at all. i use the billing portals specifically for subscription management. so I don't think a user would make a purchase which creates a subscription, then attempt to search for that subscription to cancel or edit information within the 60 seconds it takes for the search api to be queryable for it

#

I store the ids of the subscriptions. I just don't want to expose the ids. are there other alternative ways I'm not getting?

brave bobcat
#

I just don't want to expose the ids.
Can you elaborate on this? You don't have to expose the IDs of the Subscriptions.

If you're captured the IDs of the Subscriptions, then you can retrieve them directly rather than doing a Search for them:
https://docs.stripe.com/api/subscriptions/retrieve

Maybe I'm not fully grasping the flow that you're using the Search API to power?

raven leaf
#

here's an example of the data I'm currently exposing

{
    "success": true,
    "data": [
        {
            "status": "active",
            "currency": "usd",
            "created": 1748883115,
            "cancel_at_period_end": false,
            "start_date": 1748883115,
            "items": [
                {
                    "name": "Peridoc Pro",
                    "amount": 738.5,
                    "current_period_end": 1751475115,
                    "recurring": {
                        "interval": "month",
                        "interval_count": 1
                    }
                }
            ]
        },
]
}
#

then the user submits a request to create a billing portal, which sends this

{"actionOpts":{"type":"subscription_update","created":1748883115},"currency":"USD","locale":"en"}
#

Because I need the subscription id to create a deep flow to the management of that subscription in the portal, I perform a search in the backend

#

This works because a user can only ever have one customer object per currency

brave bobcat
#

Okay, here's what I'm hearing you do now, please let me know if I'm misunderstanding:

  1. listen to customer.subscription.created Events
  2. capture the created time from the above Event
  3. later, make a request to the Search API using just the created timestamp to find the Subscription that was surfaced in the Event from Step 1
  4. Using the ID of the returned Subscription object (to create a billing portal session, and/or to surface related information about the Subscription)
raven leaf
#

I'm not listening to the events at all, sorry that I'm not explaining it correctly

#

I'm creating a table of active subscriptions for subscription management, which the user can then use to update it

image.png
brave bobcat
#

Ah, I see. Where are you getting the value for the created timestamp from then?

raven leaf
#

When fetching the data for the table, I first retrieve all customers the user owns, and then all subscriptions for those customers which are active. Finally, I create a data transfer object with only safe fields exposable to the user. The created field was ideal for me because its vague enough an attacker can't glean information from it, but I can still use to associate any billing portal creation for

#

the app isn't live yet so subject to change (:

brave bobcat
#

I think I'm starting to grasp the stumbling point here. Am I correct in understanding that you don't have a sort of "private" storage for your flow? Like everything is exposed to the customer, which is why you're trying to use non-sensitive values?

The ID of the Subscription isn't really sensitive, nor descript about what the Subscription contains. The ID of the Subscription can't be used to do anything without your secret API key, so if you keep that key a secret the ID of the Subscription isn't confidential.

raven leaf
#

lol not at all. Nothing is exposed. I have access to any amount of storage necessary

#
  1. I could use encrypted cookies to store the ids along with the public info
#

it was just easiest to have it all stateless

brave bobcat
#

I really do think storing IDs is going to be the better approach. It's going to remove any ambiguity when it comes to retrieving the Subscriptions you want.

For instance, your customers can only check out for one Subscription at a time. But I'm not sure if there is anything preventing two distinct customers from creating a new subscription, each, simultaneously. Since the Search API doesn't accept a customer parameter when searching Subscriptions, you potentially have to do extra processing on extra results to see which ones have a customer field that matches the Customer logging into your portal.

If you track exact IDs, it removes the need to do any sort of fuzzy matching, and I think it may have better performance as well.

raven leaf
#

Oh don't worry about that part specifically. I first confirm that the email associated with the retrieved subscription matches the user authenticated. but you are correct that this is the hard way, and using the ids directly would be better for performance

raven leaf
brave bobcat
#

I do still think our teams should dig into the Search API behavior you flagged, and I am going to still be reporting that for further investigation (after doing a bit more digging in my test account).

The List endpoints also support the use of expand, as do Retrieve endpoints.

raven leaf
#

oh you're right, the list api also accepts a created field. I wonder if it has the same accuracy issue?

brave bobcat
#

That's actually next on my list of things to test 😅

Whether it returns results based on the created timestamp we show you on the object, or a different one (what seems to be happening to here)

raven leaf
#

that would be hugely helpful. though it may have been unintentional to have anything other than the ids to find unique subscriptions when a user can have more than one customer/subscription, it would be nice to have the option

slate rivetBOT
#

Hello @raven leaf, we have sent you a direct message, please check it at https://discord.com/channels/@me/1381662110068768798

  • 🔗The message has instructions on how to open a direct support case with our Developer Support team, in order to help you more effectively.