#nickdnk
proud pikeBOT
Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
spiral saffron
Gotcha, thank you for the feedback. I will raise this internally but can't promise if/when this will be addressed.
sour charm
Coming to think of it even the timestamp in the error wouldn't help at that just tells me that the payout was created after the cutoff.
spiral saffron
That being said, I do see an event that sounds like what you are describing. I assume you've already tested and it does not trigger here? https://stripe.com/docs/api/events/types#event_types-reporting.report_type.updated
sour charm
No I'm creating a report run in response to a payout; I'm not waiting for a report run
Or is this just firing randomly for when some data becomes available?
I guess this could work, but it would require that I redesign my integration a bit
I could create the payout row on payout.paid but not run the report until I get this webhook and payouts with no report exist after the timestamp?
Am I understanding this correctly?
spiral saffron
I am honestly not that familiar with events and report runs. Will consult my colleagues and get back to you
sour charm
Alright thanks
spiral saffron
It looks like that should be how this works and you can also retrieve the current available date range via the API https://stripe.com/docs/reports/api#data-availability
Unfortunately as far as we can tell there aren't specific timelines for new availability, it may be as much as 12 hrs for some reports but I am unsure what it looks like for this kind of report
sour charm
Okay I thinnk I can work with this though, I'll just add another webhook that checks for payouts without a report generated after the data_available_start property of the event
and then I'll ignore the error I get when I run the report in response to payout.paid
that should cover all cases
I am correct to assume that the event is fired for each connected account?
spiral saffron
Awesome! Glad we did already have something usable here. Also we just found something that said this report can take even longer, like multiple days, for cases where things like IC+ are involved. So 12 hours is not always the rule of thumb for the max
sour charm
(and that the availability timestamp and time of the event may differ)
spiral saffron
If you are running this report per connected account, I would think so. If this is a platform level report, I can check with my colleagues
sour charm
It's for connected accounts
not platform
standard accunts
My point being that I can just select payouts that belong to the particular account of the event when looking for payouts with no report on my end
spiral saffron
Yep, that should be how that works here
proud pikeBOT
sour charm
Great thanks
sour charm
I'll have to ask what the timestamps actaully encompass
Does data_available_start go back to the end time of the previous event for that report type? Or is it just "the beginning of time", i.e. the first payout always
oak meadow
Hello! I'm taking over and catching up...
sour charm
Sure
I guess what I'm asking is which of the two timestamps I should use to find all payouts that can now be safely included in my report runs
oak meadow
As I understand it data_available_start is going to indicate the earliest data available for the report type in question, meaning you could run a report on data starting at that point. It's usually around the time your account started producing said data, unless that was a long time ago and some older data is no longer available (but I'm not sure how long we retain this data).
sour charm
Okay, so that is not expected to change
I should select all payouts created before data_available_end instead
and not all payouts created after data_available_start
(while filtering to those that have no report yet, of course)
oak meadow
It might change, but as long as you're working with recent data it shouldn't matter.
sour charm
In this context I mean it won't change to a meaningful/useful value
oak meadow
Yeah, I would anchor on data_available_end and go backwards if you want reports for recent stuff.