Overview

All Dynamic Planner APIs follow a clear, predictable request model based on REST and JSON. Every request must include the required authentication headers and target the correct environment and API domain. This guide explains the required headers, HTTP methods, content types, base URL structures, and diagnostic fields used throughout the platform.

Base URL Structure

All Open API endpoints share a common root:

https://open-api.dynamicplanner.com

Examples:

• CRM API — /crm/v1
• Finances API — /finances/v1
• Profiling API — /profiling/v1

Environments (Development and Production) use the same base URL; access is determined by the subscription key provided during onboarding.

Required Headers

Every request must include two authentication headers:

• Authorization: Bearer <access_token> — OAuth 2.0 access token.
• Ocp-Apim-Subscription-Key: <subscription_key> — Identifies your application.

Additional recommended headers:

• Accept: application/json
• Content-Type: application/json
• x-dt-traceid — Optional client-provided correlation ID for tracing.

GET /crm/v1/clients HTTP/1.1
Authorization: Bearer 
Ocp-Apim-Subscription-Key: 
Accept: application/json
            

HTTP Methods

Dynamic Planner APIs follow standard REST semantics with a key platform-specific convention: PUT is used for both creating and updating resources. POST is only used in exceptional cases where an operation does not fit the create/update pattern.

• GET
  Retrieve data. Safe and idempotent.
• PUT
  Create or update a resource. Dynamic Planner uses PUT for both initial creation and subsequent updates. Idempotent — repeating the same request produces the same result.
• DELETE
  Remove a resource. Safe to retry if the resource no longer exists.
• POST
  Rarely used. Reserved for special operations that are not resource-oriented or do not align with standard create/update behaviour.

Query Parameters

Query parameters are used for filtering, pagination, field selection, and partial expansion of data. Dynamic Planner uses predictable patterns:

• Pagination: pageSize, pageNumber
• Filtering: fields, questionnaireId, unions
• Array parameters: comma-separated lists using style=form and explode=false

GET /clients/{clientId}/results?pageSize=50&pageNumber=1&fields=factors
            

Request Bodies

POST and PUT endpoints expect JSON request bodies. Required and optional fields are documented in the API reference and visible in the Swagger definitions.

{
  "clientId": "11111111-2222-3333-4444-555555555555",
  "name": {
    "firstName": "Jane",
    "lastName": "Doe"
  },
  "dateOfBirth": "1990-01-10"
}
            

Unknown or unrecognised fields are safely ignored unless explicitly validated by the endpoint’s schema.

Diagnostic Headers

Every Dynamic Planner response includes diagnostic headers to help trace issues through the system:

• x-dt-requestid — Server-generated request identifier.
• x-dt-traceid — Echoed back if provided by the client.

Logging these values helps support teams diagnose issues, especially when working with error responses or retry scenarios.

Common Request Patterns

Retrieving a Single Item

GET /crm/v1/clients/{clientId}
            

Retrieving a Paginated List

GET /finances/v1/clients/{clientId}/holdings?pageSize=25&pageNumber=1
            

Creating or Updating a Resource

PUT /finances/v1/clients/{clientId}/pensions/{pensionId}
Content-Type: application/json

{ ... }
            

Best Practices

• Always include the required authentication headers.
• Use pagination for all list endpoints.
• Use filters to reduce payload sizes.
• Log diagnostic headers for support (request IDs + trace IDs).
• Implement retries only for temporary errors (429, 500, 503).
• Design PUT requests using idempotency.