I really want to love this, but my experience in the first 20 seconds is unfortunately like some of my other experiences coding against Fly APIs, they're broken.

https://sprites.dev/api has this command:

$ curl -X POST "https://api.sprites.dev/v1/sprites" \ -H "Authorization: Bearer $SPRITES_TOKEN" \ -d '{"name": "my-sprite"}'

which responds with

{"error":"name is required"}

if you use the request body in the full "Create Sprite" documentation at https://sprites.dev/api/sprites#create then it does work.

can I live with some rough edges for some personal workflows that only impact me when things break? sure. however, I was thinking about playing with some CI/CD stuff using sprites that would impact our whole team if things broke and I'm really on the fence because of this experience in the first 20 seconds.

Fly team - please put some black box probes or just better testing on the example you give in the quick start. if you document it, test it.

Believe it or not, that's the only example that's not autogenerated from tests (yet).

https://github.com/superfly/sprites-js/tree/main/examples https://github.com/superfly/sprites-go/tree/main/examples https://github.com/superfly/sprites-py/tree/main/examples https://github.com/superfly/sprites-ex/tree/main/examples

Probably because you didn't include the content type header?

Can this issue be reported?

I wish more companies had open issue trackers (some proprietary software have issues on Github for example, but, it doesn't need to be Github, just let people discuss issues in the open)

The documentation is correct now. I assume someone from fly is reading the comments.