Planned features
What's planned for the Developer API after its first version, including service keys, write scopes, webhooks from Halo Data, IP allowlists, SDKs and a CLI. None of it exists yet.
Planned. This describes something on Halo’s roadmap that isn’t in the product yet.
| Planned | What it would do | What to do today |
|---|---|---|
| Service keys | Keys owned by the organization, so an integration doesn't stop when the person who made its key leaves or changes their password | Use a person's key, and alert on 401 invalid_api_key |
| Write scopes | Make reports, publish, and manage shares and exports through the API | Do these in Halo Data. Every key and every tool only reads |
| Webhooks from Halo Data | Hear when a report is published, an extract is refreshed or a delivery fails. Halo CRM's events work today | Poll, within your rate limits |
| IP allowlists | Limit a key to the addresses you name | Keep keys on your own servers. Owners and Admins can see each key's last address under Settings, API access |
| SDKs | Published TypeScript and Python clients, generated from the OpenAPI file | Generate a typed client |
| A CLI | A halo command that signs in through the browser | Use cURL |
| Secret scanning | Register hak_, hpat_ and hes_ with GitHub's partner program, so leaked keys are revoked automatically | Scan for those prefixes yourself, and act on a leak |
Why service keys take more than a new key type
A key today is one person, and Halo's access levels and row policies are worked out for a person. A key owned by an organization needs a principal that isn't human in those checks, so that what it can read is as clear as it is for a member.