discodanne_api

[balmy grove]

👋 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/1447889558992850985

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

[raven turret]

Taking a look

Indeed, this seems unexpected to me. Let me quickly try and reproduce the issue

To answer your other question:

Can we check the permissions of a restricted key via the API?
No
Is there any documentation of what permissions is releated to which API endpoints?
Not explicitly but it's inferred from the object/resource naming (e.g. Payouts -> payout_read/payout_write)

[raven turret]

Still checking on this

OK, looks like payout_read is inferred from the rak_balance_transaction_source_read permissions which your key has

FWIW, this is highlighted in the Dashboard UI for restricted keys

[orchid cypress]

So the only way for us to know the permisions is to test it?

To validate that a key have payout write we need to write to a payout?

[raven turret]

I don't know what you mean? If any permissions implies other permissions, like the above, then they'd be listed on that page. Otherwise you can assume 1:1 mapping for read/write on the associated API resource

[orchid cypress]

Is there any get call that requre the payouts read permision. or do we need to update a payout to verfiy that we have the permision?

[raven turret]

Yes, you can't lookup a key via the API. You'd either just attempt the API call, or look at its permission in the Dashboard

[raven turret]

Yes, any GET endpoint will need the corresponding read permission for that resource

So, GET /v1/payouts (like your example), GET /v1/payouts/:id

Overall I'm not really sure what you're trying to verify

[orchid cypress]

Since all is user driven on our end, the customer brings their own apikey. If we cant write metdata to a pyout that will cause sideeffects so to prevent unwanted sideeffects with the lack of the correct permisions we want to add an intermediate step to verify the permision before we start

[raven turret]

Yeah, you can't really. You'd just need to make the POST /v1/payouts/:id call and act on the outcome

[orchid cypress]

Would it work to just send an empty update? Or will that get stuck on other validation?

[raven turret]

This is why generally we discourage building platforms/plugins with restricted keys

[raven turret]

It'll fail regardless of the payload if the key doesn't have the required permission(s)

[orchid cypress]

Yeah that is kind of the point to see if it fails then we know we should not run any other parts

But what would you recommend if restricted keys arent the solution

[raven turret]

Depends on what exactly your app/plugin is

[orchid cypress]

Its automatic bookkeeping between Stripe and Fortnox.
It runs on a schedule and reads, charges, refunds and payouts and bookkeep them accordingly.
We write back metadata to keep track of what have been handled thats why we need the write permision

[raven turret]

You'd probably use a Stripe App then: https://docs.stripe.com/stripe-apps/plugins/oauth

Users install your app on their Stripe account and it gives your platform access to their account with the configured permissions

[orchid cypress]

Okey sounds like a better option. We will look into porting our current integration to use the ouath flow instead. Thanks for your time

[raven turret]

np!