The very first version, the one which can be accessed at api.bitrise.io right now does not. It has basically three endpoints:
/me - get info about yourself (the authenticated user)
/me/apps - list of your apps/projects
/me/apps/XX/builds - get the list of builds of the app
But getting build artifact infos is high on our priority list, shouldn’t take long to get there 
That’s really good news. Thanks for all the hard work, keep it up.
We definitely will, thanks for the support
Personal Access Token UI is finally available on bitrise.io
API Docs are coming soon 
I’m getting 404 on the /me endpoint. Is there an example of the full url or even how to pass the PAT?
@tomcurran docs are coming soon, hopefully tomorrow. As a preview, to call the /me endpoint with curl:
curl -H 'Authorization: token ACCESSTOKEN' https://api.bitrise.io/v0.1/me
Where Acess Token is the token you can generate on your Account Settings page, under Security -> related #changelog : Personal Access Tokens (BETA)
It looks like the /me and /me/apps endpoints are working for me, but not the /me/apps/xx/builds endpoint (where I have replaced xx with the output from /me/apps). Is that expected?
It looks like right now this is actually under /apps/xx/builds (without the /me indicated above)
We just deployed the last couple of changes we wanted to do before the “public beta”, the current API docs can be found at:
http://discuss.bitrise.io/t/bitrise-api-v0-1-work-in-progress/1554
Please keep in mind that this is work in progress, new endpoints will be added soon. There are still a couple of technical details we have to talk though, but we think that the base structure of the API is sufficient to build upon.
If you have any questions feel free to ask here, or leave a comment at the API docs topic.
Hi @viktorbenei,
This is already super useful and thanks for the public beta !
Could i bother you to add asap the following endpoint:
GET /apps/{APP-SLUG}/builds/{BUILD-SLUG}
My use case is as follow: I use the trigger API to start a build, which give me back the BUILD-SLUG and I want to query the build status of that build specifically. At the moment, I have to retrieve the list of builds of the app and then find my build inside it which is a waste of resources and bandwidth on both sides.
Thanks in advance !
Added to the WIP section at Bitrise.io API v0.1 (Work In Progress)
Thanks for the request @Tlvenn
Hi,
Would it be possible to add a little more info about the commit from thich the build was triggered? Just a simple addition with author’s data besides just the commit hash?
@barendarski sure - what data/infos would you like to get? Please provide the full list if possible.
Currently we have commit_hash returned from Bitrise’s API.
I’d love to also get, if it’s a repo that supports it (git for example), commit’s
Author and Date fields.
By the way, would it be possible to get latest builds of all apps associated with the token? Or is it a performance issue?
This is just so I don’t query the API for every app’s slug every time I want to get an overview.
The /apps endpoint returns infos for all apps, but indeed that does not include any info about the latest build. It most likely won’t, because what infos you need about every app depends on what you need it for, can be quite different for different use cases.
That said we’ll provide API endpoints to quickly query a specific app’s latest build infos. You’ll still have to call that for every app, but you’ll be able to parameterize it, e.g. to get the latest build on a specific branch, including or excluding PRs, etc.
Awesome, thanks for clarifying.
I’m looking forward to expanding build’s commit info.
@Tlvenn done, sorry for the long delay -> Bitrise.io API v0.1 (Work In Progress)
Thanks @viktorbenei !
I’d like to see an API endpoint for manage the app’s cache on bitrise.
My current idea is that the cache should be created once a week with an “only cache” build.
For example I cache the global node packages and the local node packages.
With this I’m saving a lot of time on my builds.
But the Cache:Push is really time expensive - and not needed for me.
So I’m developing an small thing for me which triggers a “only cache regeneration build”.
@patrick.bussmann you can do that by not including the Cache:Push step in the workflows where you don’t want to, and have a separate workflow where it’s included, then run that workflow once a week (e.g. Schedule a build for that on bitrise.io).