Skip to main content

Update information in MyCRM

An integration can create or update information in MyCRM on behalf of an adviser. Before making a change, decide whose adviser context should apply and which records your application is allowed to change. For example, a new website lead should be allocated to the adviser responsible for following it up.

Your application credentials identify the integration. The UserId request header identifies the adviser it is acting for. Both are needed for the usual client-credentials write workflow; successfully reading a record does not prove that you have supplied the context needed to update it.

What to put in UserId​

Use the adviser's contact identifier, also called AdviserContactId. It is a numeric value, such as the fictional 2042 used below.

Authorization: Bearer {ACCESS_TOKEN}
UserId: 2042

Send it with each write request, including POST, PATCH, PUT and DELETE where the endpoint supports them. It provides context for recording who created or last modified information and for allocating a new lead. The adviser must be covered by your application's permitted access; changing this header does not grant extra permissions.

A small number of GET endpoints also need to know who the user is to work. Supply the same UserId header when a read endpoint requires adviser context; do not assume it is unnecessary just because the request only reads information.

The adviser contact identifier is different from the advisers resource ID. It is also different from a client's contact ID, an organisation ID, a login email address or an OAuth client ID. Use one of the two methods below to obtain it.

Option 1: Find the adviser through the API​

If your application is allowed to search adviser-details, look up the adviser you intend to act for. Use an appropriate granted search scope and confirm the person's identity from the returned details.

This example searches by email. Replace the fictional email with the adviser's actual address:

curl --globoff --get "${API_BASE_URL}/jsonapi/adviser-details" \
  --header "Authorization: Bearer ${ACCESS_TOKEN}" \
  --header "Accept: application/vnd.api+json" \
  --data-urlencode "filter=equals(email,'alex.taylor@example.com')" \
  --data-urlencode "include=adviser"

An illustrative excerpt from the response:

{
  "data": [
    {
      "type": "adviser-details",
      "id": "2042",
      "attributes": {
        "firstName": "Alex",
        "lastName": "Taylor",
        "email": "alex.taylor@example.com"
      },
      "relationships": {
        "adviser": {
          "data": { "type": "advisers", "id": "91" }
        }
      }
    }
  ]
}

Use data[].id from the correct adviser-details resource: UserId: 2042 in this example. The related advisers ID, 91, is not the header value. An included adviser resource can help you confirm which adviser the contact details belong to.

Do not automatically select the first result if multiple records match. Confirm the adviser and organisation, follow pagination when needed, and store the verified identifier with that adviser's integration configuration. If you already know an advisers resource ID and have the appropriate read access, you can follow its adviserDetails relationship and use the returned adviser-details ID.

See Search adviser details. If your credentials do not permit this lookup, use the API Settings screen instead; you do not need directory access just to obtain the header value.

Option 2: Copy it from API Settings in MyCRM​

  1. Ask the adviser whose context the integration will use to sign in to MyCRM.
  2. Open Profile Management → API Access Management, the API Settings screen.
  3. Find Your User Id and copy the displayed number using the copy control.
  4. Put that number in your integration's UserId header. In the supplied Postman collections and sample client configuration, the corresponding setting is named AdviserContactId.

Your User Id belongs to the person signed in. If a business owner or administrator helps with setup, confirm that the copied value belongs to the intended adviser. For an integration that works for several advisers, keep a verified mapping and select the appropriate value for each request.

If the screen is unavailable, ask your head adviser or business owner to help you obtain the correct adviser contact identifier. You do not need to generate replacement credentials simply to read the identifier.

Make a small, deliberate update​

Use a permitted test record and send only the fields you intend to change. The adviser identifier is a header; the target contact's identifier belongs in the URL and JSON:API body.

PATCH {API_BASE_URL}/jsonapi/contacts/1001
Authorization: Bearer {ACCESS_TOKEN}
UserId: 2042
Accept: application/vnd.api+json
Content-Type: application/vnd.api+json

{
  "data": {
    "type": "contacts",
    "id": "1001",
    "attributes": {
      "email": "alex.morgan@example.com"
    }
  }
}

Here, 2042 identifies the adviser and 1001 identifies the contact being updated. Check the HTTP status before treating the change as successful; an endpoint may return an updated resource or a successful response without a body. Read the record back if your workflow needs to confirm the saved value.

See Update a contact and writing JSON:API requests for resource types, matching IDs and relationship updates.

If the request returns 403 Forbidden​

A missing, incorrect or unpermitted UserId can cause a 403 Forbidden response. Check the actual outgoing request, not just the configuration screen: the header must reach the API on the request that makes the change.

Read the error response for the reason. When adviser-context validation supplies an error body, its details can identify the missing or invalid header, including this message:

UserId HTTP header is missing or invalid

Depending on where the request is rejected, that validation message can also arrive with 400 Bad Request. An earlier authorisation rejection may return 403 without a detailed JSON:API body, so do not rely on every 403 containing this exact text.

Work through these checks:

  1. Confirm that UserId is present and contains the numeric adviser contact ID obtained above.
  2. Confirm that the value belongs to the intended adviser in the correct environment and is permitted by your application's access.
  3. Check that the access token includes an approved scope for the write operation and that the target record is accessible.
  4. Correct the cause before retrying. Repeating the same rejected request or changing IDs at random will not resolve permissions.

A 403 can also indicate a scope or data-access problem. Retain the status and sanitised error details when investigating; keep bearer tokens and client secrets out of logs. See scopes, data visibility and troubleshooting for the broader access rules.