CEagle publishes two APIs, and both are for building something of your own on top of it.
Browse the registry, resolve dependencies and download programs. This is what a calculator client talks to.
Sign people in with their CEagle account: authorization code, device flow, refresh, discovery.
What is not published#
The developer console has an API. It is not documented, and it is not a supported integration point.
Every endpoint behind it acts on somebody's account, several are protected by human verification that an automated client cannot pass, and all of them assume a browser session rather than a credential you could hold. Publishing them would mostly serve people trying to script account creation and project spam.
Which one you want#
Reading published programs
Roost. Public, unauthenticated, and the only one a calculator needs.
Signing your users in with their CEagle account
Accounts. Register an application in the console, then run an OAuth flow.
Managing your own projects and builds
The console. There is no API for it.
Authentication at a glance#
| API | How |
|---|---|
| Roost | nothing at all, and there are no writes |
| Accounts, discovery and keys | nothing at all |
Accounts, /oauth2/authorize and the device start | nothing; the client identifies itself by client_id |
Accounts, /oauth2/token | your client secret, or PKCE for a public client |
Accounts, /oauth2/userinfo | the access token, as a bearer token |
| Accounts, introspection and revocation | your client secret |
Which flow to use, and how to run it end to end.
Errors#
Roost answers with a stable error code and a message written for a person. The OAuth endpoints
answer with the RFC 6749 shape instead. Both are stable in error and neither is stable in the human
text beside it.
Every code you can get, and which are worth retrying.
Versioning#
Endpoints live under /api/v1. That prefix changes only for a break, and a break means a new prefix
rather than a change under the old one.
Within v1, fields are added and never removed or repurposed, so a client that ignores unknown
fields keeps working.
The descriptions are generated#
Both documents are built from the same Go types the handlers use, so the schemas cannot drift from the implementation.
Fetching them, generating a client, and what the generator does with validation rules.