This guide covers the practical implementation of the Axero REST API, including Bearer token authentication, performance optimization, and security best practices. Whether you're migrating from legacy API keys or building new integrations, this documentation provides the essential knowledge for successful API implementation.
The Axero REST API uses Bearer tokens for secure authentication. These cryptographically signed tokens offer enhanced security compared to traditional API keys and adhere to industry standards.
After you create your Bearer token (Creating Bearer Tokens), include it in the Authorization header of all API requests:
Authorization
📝 Request Format
GET /api/users/me Host: yoursite.axero.com Authorization: Bearer YOUR_BEARER_TOKEN_HERE Content-Type: application/json
The primary change involves updating the authorization header format in all your API requests:
Legacy key, legacy header
rest-api-key: YOUR_LEGACY_KEY_HERE
✅ Bearer token, recommended header
Authorization: Bearer YOUR_BEARER_TOKEN_HERE
What is retired is the legacy key, not the header name. A current bearer token is also accepted in the Rest-Api-Key header, and that form is still supported on purpose: on a self-hosted site that uses Windows Authentication, the web server claims the Authorization header for its own credential negotiation and refuses the request before Axero sees it. Sending the token as Rest-Api-Key leaves that header free and needs no server change, so it is the first thing to try there. The other route, opening anonymous access to the /api path alone, is described on Active Directory SSO.
Rest-Api-Key
/api
Everything on this page assumes the request reaches Axero. On a self-hosted site, the web server in front of Axero can refuse an API call first, most often when Windows Authentication is on and Anonymous Authentication is off, which is the configuration Active Directory SSO sets up. A request refused there never reaches the token check, so no token change will clear it. Before troubleshooting a token, confirm the request is reaching Axero at all; the 401 row in the status code table below says how to tell.
Here are practical examples showing how to implement Bearer token authentication in different programming languages and tools:
🌐 cURL Example:
curl -X GET "https://yoursite.axero.com/api/users/me" \ -H "Authorization: Bearer YOUR_BEARER_TOKEN_HERE" \ -H "Content-Type: application/json"
🟨 JavaScript Example:
fetch('https://yoursite.axero.com/api/users/me', { method: 'GET', headers: { 'Authorization': 'Bearer YOUR_BEARER_TOKEN_HERE', 'Content-Type': 'application/json' } }) .then(response => { if (!response.ok) { throw new Error(`HTTP error! status: ${response.status}`); } return response.json(); }) .then(data => console.log(data)) .catch(error => console.error('API Error:', error));
🐍 Python Example:
import requests headers = { 'Authorization': 'Bearer YOUR_BEARER_TOKEN_HERE', 'Content-Type': 'application/json' } try: response = requests.get('https://yoursite.axero.com/api/users/me', headers=headers) response.raise_for_status() # Raises an HTTPError for bad responses data = response.json() print(data) except requests.exceptions.RequestException as e: print(f"API Error: {e}")
When building widgets or content pages for your Axero site:
Security Risk: API keys and bearer tokens embedded in client-side code are discoverable by end users and create significant security vulnerabilities. Anyone can view page source, inspect network requests, or use browser developer tools to extract these credentials.
For widgets, content pages, and client-side JavaScript within your Axero site:
Example: API calls from JavaScript widgets automatically inherit the logged-in user's permissions without requiring explicit authentication.
For server-to-server integrations, external applications, and third-party systems:
Authorization: Bearer {token}
Example: External applications connecting to your Axero API must authenticate with Bearer tokens to access data on behalf of specific users.
Axero does not enforce hard rate limits on the REST API by default. However, to ensure consistent performance, reliability, and a smooth experience for everyone, we recommend adhering to the best practices outlined below. These guidelines are intended to support high-performance, scalable integrations while preserving the responsiveness of your Axero environment. Axero may apply temporary rate restrictions if excessive API usage affects overall site performance.
200
401
403
429
500
The Axero REST API is organized into several categories, each providing specific functionality for different aspects of your intranet platform. Each category includes comprehensive endpoints for creating, reading, updating, and managing data:
Comprehensive user management capabilities for creating, updating, and managing user accounts and roles.
Powerful content management tools for creating, retrieving, and managing all types of content within your intranet.
Complete space management functionality for organizing your intranet into departments, teams, or project areas.
Real-time messaging capabilities for integrating chat functionality with external systems and workflows.
Engagement tools for managing comments and discussions across all content types in your intranet.
Security and access control tools for managing user permissions and role-based access throughout your intranet.
Employee recognition and gamification tools for building engagement and celebrating achievements.
Comprehensive analytics and reporting capabilities for understanding community engagement and content performance.
If you need assistance, open a support case and include the following information:
GET /api/users/me
is requesting access to a wiki that you have locked: https://my.axerosolutions.com/spaces/5/axero-documentation/wiki/view/108975/using-the-rest-api
Your session has expired. You are being logged out.