Migrating from the old docs

The previous developer site documented a single recognition endpoint and an early base URL. The API has grown since then. This guide maps the old shape to the current one.

What changed at a glance

Authentication is unchanged

You still authenticate with the x-api-key header, and keys are still generated at my.happily.ai/integrations. No changes are needed to how you sign requests. See Authentication.

Base URL and stages

The base URL is versioned with /1 and scoped by stage. Use prod for live data and dev for testing:

https://api.happily.ai/prod/1
https://api.happily.ai/dev/1

The old examples used the dev stage. For production traffic, switch to prod and a production key.

Reading recognition

The old docs showed a path-style read:

GET /1/recognition/recipient/{member_email}

The current, actively maintained endpoint is query-style and also supports reading by team:

GET /1/recognition?email=jordan@acme.com
GET /1/recognition?team_name=Design

It returns a recognitions array and a pagination object. See Build a recognition bot.

Sending recognition

Sending recognition is largely the same: POST with the sender's email in the path and recipients in the body.

POST /1/recognition/{member_email}

The recipients field accepts a single email, a comma-separated string, an array, ALL_MEMBERS, or a team/cohort ID. See the recognition recipe.

New since the old docs

Everything below is new. Explore each in the API Reference:

• Members — import/sync (POST /api/v1/members), list (GET /members), profile (GET /api/v1/users/{email}/profile).
• Surveys — questions (GET /questions) and responses (GET /responses).
• Performance — boosts (POST /api/v1/performance-boosts), feedback (GET /1/performance_feedback), presets (POST /api/v1/performance-preset).
• Town Hall — content generation (POST /townhall/content).

Questions?

Email support@happily.ai. Include your company name and the endpoint you're integrating, and we'll help you migrate.