API Documentation
Welcome to Planner API documentation. Choose a link from the navigation menu on the left to view the documentation.
Alternatively, view our Endpoint Explorer to get a list of endpoints, check example requests and view model properties.
If you need any further help or support, click on the support link below.
This documentation provides a comprehensive outline to the Planner API, a RESTful API for retrieving events from Forward Planner.
API Overview
The Forward Planner API is a RESTful web service that provides access to Forward Planner events, including support for querying and filtering results.
Base URL
API Version
Current version: v2
Data Format
All data is returned in JSON format with UTF-8 encoding.
Audience
Intended for developers integrating with the Planner system.
Terms of Service
Available at Planner Terms
Authentication
The Forward Planner API uses API key authentication for secure access to data.
API Key
Include your API key in the request header:
Authorization: Bearer your_api_key_here
Getting your API Key
- Log into your Forward Planner account
- Navigate to API Settings in your account profile
- Generate or copy your existing API key
Important: Keep your API key secure and never share it publicly.
Authenticate
Endpoint: POST `/api/v2/auth`
- Authenticate with username and API password.
- Returns an access token and refresh token. Use the access token for subsequent requests.
- Example request using curl:
curl -X POST /api/v2/auth \
-H "Content-Type: application/json" \
-d '{
"username": "your_username",
"password": "your_api_password"
}'
- Example Response (200 OK):
{
"userId": your_userId,
"productId": your_productId,
"email": "your_email",
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"refreshToken": "dGhpcy1pcy1hLXNhbXBsZS1yZWZyZXNoLXRva2Vu..."
}
- If the request fails (e.g., invalid credentials), you will receive a `401 Unauthorised` error.
Renew Token
Endpoint: POST `/api/v2/auth/renew`
Best Practice
- Store refresh tokens securely (e.g., in encrypted storage).
- Implement token expiration handling in your client code.
- Refresh proactively (e.g., 1 minute before expiry).
FAQ
A: Use the POST /api/v2/auth endpoint with a JSON body containing username and password. On success, you’ll receive an object with an access token and refresh token. Include the access token in the Authorization: Bearer <token> header for all other requests.
A: The access token is valid for 15 minutes. Use the POST /api/v2/auth/renew endpoint with a refresh token to obtain a new access token.
A: If you receive a 401 Unauthorised response, use the POST /api/v2/auth/renew endpoint with your refresh token to get a new access token. If the refresh token is invalid or expired (valid for 30 days), re-authenticate using POST /api/v2/auth.
A: Store refresh tokens securely in a server-side environment (e.g., encrypted storage or a secure vault). Avoid exposing them in client-side code or unsecured databases.
A: Verify that your access token is valid and included in the Authorization: Bearer <token> header. If expired, renew it using POST /api/v2/auth/renew. If the issue persists, re-authenticate or check your credentials.
Error Handling
All errors return a JSON payload with error and message fields.
Common status codes
| Status Code |
Description |
Example Scenario |
| 200 |
OK |
Success Response |
| 400 |
Bad Request |
Invalid query parameters or input |
| 401 |
Unauthorised |
Missing or invalid access token |
| 403 |
Forbidden |
Insufficient permissions (e.g. for specific events) |
| 404 |
Not Found |
Endpoint or resource (e.g. Event ID) does not exist |
| 429 |
Too Many Requests |
Rate limit exceeded |
Best Practice
- Always check the status code and parse the error message for debugging.
- Log errors and implement retry logic for transient issues (e.g., 5xx server errors, though rare).
FAQ
A: A 400 Bad Request indicates invalid or missing parameters, such as an incorrect date format or missing required fields in the request body. Check the endpoint’s parameter requirements and validate your input.
A: A 404 Not Found error occurs when the requested resource (e.g., event, company, or saved search ID) does not exist or is unavailable. Verify the ID or parameters used in the request.
A: Check HTTP status codes in responses. For 401, renew or re-authenticate; for 400, validate inputs; for 403/404, confirm permissions or resource existence. Log errors for debugging and implement retry logic for transient issues.
Rate Limiting
To ensure fair usage and system stability, API requests are rate-limited.
Limits
- 500 requests per minute, 3,000 requests per hour and 10,000 day (per account).
- Some public endpoints have a lower threshold.
- Exceeding limits returns a 429 Too Many Requests response with headers like Retry-After (seconds until retry).
Best Practice
- Implement exponential backoff in your client (e.g., retry after 1s, then 2s, etc.).
- Monitor usage via response headers (e.g., X-Rate-Limit-Remaining).
- For high-volume needs, contact support to discuss increased limits.
Example 429 Response
{
"error": "Throttle Limit Reached",
"message": "You have exceeded the rate limit. Retry after 60 seconds."
}
FAQ and Best Practices
Some common questions and best practices for using the API.
A: Use the GET /api/v2/events/date endpoint with a date parameter in YYYYMMDD format (e.g., 20250924). Optionally include offset and limit for pagination. Ensure you have a valid access token.
A: Yes, use the GET /api/v2/events/between endpoint with startDate and endDate parameters in YYYYMMDD format. For example, startDate=20250924&endDate=20250930.
A: Use the GET /api/v2/events/latest endpoint with a date (YYYYMMDD) and optional time (HHMM, default 0000) parameter. Set updatesOnly=true to retrieve only updated events. Events are ordered with most recently updated appearing last in the list.
A: A saved search is a predefined query stored in the Forward Planner system. Retrieve saved search IDs using GET /api/v2/searches, then use GET /api/v2/events/savedsearch/{id} or GET /api/v2/plannedevents/savedsearch/{id} to fetch events or planned events for that search.
A: A 403 Forbidden error indicates that your user account lacks permission to view the requested event or planned event. Verify your access rights with the system administrator.
A: Most endpoints support offset (starting record, default 0) and limit (number of records, default 100) query parameters. For example, GET /api/v2/events/date?date=20250924&offset=100&limit=50 retrieves the next 50 records starting from the 101st.
A: Events (/api/v2/events/*) represent confirmed or public events created and maintained by our Editorial team, while planned events (/api/v2/plannedevents/*) include additional metadata like ratings and custom fields, typically for user created or events added to the Planner by someone in your team in Forward Planner.
A: tbcTime (boolean) indicates if the event time is "To Be Confirmed." Similarly, tbcVenue indicates if the venue is not yet finalised. Check these fields to handle provisional data.
A: Dates must be in YYYYMMDD format (e.g., 20250924 for September 24, 2025). Times, where applicable (e.g., /api/v2/events/latest), use HHMM format in UTC (e.g., 1345 for 1:45 PM).
A: The embargoTime (date-time) indicates when an event’s details are restricted from public release. Ensure your application respects this restriction if applicable.
A: Use the q query parameter in endpoints like GET /api/v2/filtertypes/companies or GET /api/v2/filtertypes/categories to filter by keyword. For example, q=tech may return companies with "tech" in their name.
A: Custom fields and custom tags allow users to add user-defined metadata to planned events. They include IDs, values, and labels or group information for flexible event customisation.
A: Use pagination (offset and limit) to manage large datasets, cache filter data (e.g., countries, timezones) that changes infrequently, and renew tokens proactively before expiration.
Troubleshooting
Some common troubleshooting steps for API issues.
A: Check your network connection, ensure the API host is correct, and verify the server is operational. If the issue persists, contact the API support team.
A: Missing events may be due to permissions (401/403 errors), incorrect date formats, or filtering by a saved search that excludes certain events. Verify your query parameters and access rights.
A: In the GET /api/v2/events/latest or GET /api/v2/plannedevents/latest endpoints, deleted events are returned with the deleted field set to true and include a deletionDate value.