Stripe adds metadata to API(stripe.com)
stripe.com
Stripe adds metadata to API
https://stripe.com/docs/api#metadata
8 comments
We're already supporting Stripe's metadata over at Stunning in our receipt emails for customers, and rolling it out to our other email types in the near future (http://blog.bestunning.net/stripe-metadata-support-for-stunn...)
I love it! It's a perfect example of what makes Stripe a great company. This feature is in no way necessary, it's just icing on the cake. I wish more companies would address API usability issue like Stripe does.
Sweet! Been using the description field to store my metadata currently but this is a huge step up in terms of structuring the data and being able to search it if necessary.
Kudos to Stripe!
Kudos to Stripe!
I wish this sort of thing were more common. For debugging purposes if nothing else, it's helpful to support custom metadata everywhere in an API -- every data type, every logged operation.
I agree.
And also, because a lot of the power of APIs comes from the unexpected ways in which people use them I think API providers should encourage unexpected use-cases.
We've just finished doing a similar thing to Stripe, having built an "attributes" key:value store against pretty much anything in our API: http://microcosm-cc.github.io/#attributes
One of the goals we have from that, even without knowing the use-cases behind it, is to have the attributes be first class entities.
Such that you can find things by their attributes, or set up permissions with things like "people with this attribute can do that".
APIs can be really constricting or they can be liberating. Obviously the provider of an API needs to support whatever the API does, and usually this means that the API goals must match the goals of the provider. But in things like metadata/attributes/extended data... there is a real potential to offer a powerful capability that can be supported by the provider and yet allows the API developer to define the use-case themselves.
And also, because a lot of the power of APIs comes from the unexpected ways in which people use them I think API providers should encourage unexpected use-cases.
We've just finished doing a similar thing to Stripe, having built an "attributes" key:value store against pretty much anything in our API: http://microcosm-cc.github.io/#attributes
One of the goals we have from that, even without knowing the use-cases behind it, is to have the attributes be first class entities.
Such that you can find things by their attributes, or set up permissions with things like "people with this attribute can do that".
APIs can be really constricting or they can be liberating. Obviously the provider of an API needs to support whatever the API does, and usually this means that the API goals must match the goals of the provider. But in things like metadata/attributes/extended data... there is a real potential to offer a powerful capability that can be supported by the provider and yet allows the API developer to define the use-case themselves.
I'd love metadata to be added to more kinds of purchases, by debit card for example, beyond just the name of the retailer - it'd create such a wealth of valuable data that one could do so many interesting things with.
Can I store metadata on a subscription? I actually am planning on one dollar subscriptions with a quantity equal to the sum of all monthly subscription fees just so that Stripe will do the bookkeeping etc for me. Since it says max ten key I might dump a lot in one key as JSON including a list of the actual subscribed plans.
What I really want is multiple plan subscriptions per customer e.g. one $15/month server and 2 $7 per month servers. Obviously I can just do that as metered but it seems like a lot more code and testing and something I could easily screw up. So having multiple plans subscribed per customer would be nice.
What I really want is multiple plan subscriptions per customer e.g. one $15/month server and 2 $7 per month servers. Obviously I can just do that as metered but it seems like a lot more code and testing and something I could easily screw up. So having multiple plans subscribed per customer would be nice.
For those who don't have a use case, make the use case a simple security measure. For instance, create metadata for the persons name and perhaps tie it back to objects in your db. This way, you can easily rebuild transaction history if ever it is lost.
This is awesome for us, because although the "customer details API" step was optional, it's was the most complicated part of our on-boarding process for new customers, and really addressing people by first name (at the very least) in an email is a bit important. Now we really do have a "zero-code" on-boarding process.