Answers.Body: <p>For portability reasons, APIv4 does not use the &quot;custom_id&quot; identifier but instead uses &quot;CustomGroupName.CustomFieldName&quot; as the field key.</p>
  <p>This is because when you migrate one site to another auto-increment ids in the database (including ids of custom fields) are not guaranteed to be consistent.</p>
  <blockquote>
  <p>Wouldn't be nice to put a field ID at a 1st place</p>
  </blockquote>
  <p>No, that would not be portable as the name would include field id. Names can be relied upon as stable between different sites, ids cannot. It's also not human-readable (unless you have memorized the ids of all 666 of your custom fields, the number is meaningless and makes your code hard to understand).</p>
  <p>To directly answer your question, the analogue of this:</p>
  <pre><code>civicrm_api3('Contact', 'get', [
    'return' =&gt; ['custom_123'],
  ]) ;
  </code></pre>
  <p>Is this:</p>
  <pre><code>civicrm_api4('Contact', 'get', [
    'select' =&gt; ['CustomGroupName.CustomFieldName'],
  ]);
  </code></pre>
  <p>You can also conveniently return all values from a custom group (not possible in api3) like this:</p>
  <pre><code>civicrm_api4('Contact', 'get', [
    'select' =&gt; ['CustomGroupName.*'],
  ]);
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-15T11:43:33.937Z
Answers.Text: Thank you, I trust the decision of using text labels instead of IDs has been made by the high priests aiming to benefit all of us and is not reversible. A few more notes if I may: a). I fail to see how IDs interferes while site migration - normally we append new fields/field groups to an existing ones and that's it, don't we? b). Why would we memorize ID if it is right in the 1st column of the "Custom Data/Custom Data Fields" page table? c) How would you effectively  work with the API Explorer when you can see only a part of a Custom Group (not a Custom Field) label in the select?
Answers.UserDisplayName: yurg
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-15T14:58:28.163Z
Answers.Text: We don't have any priests, but we do have a lot of community-contribued extensions - when an extension wants to add a custom field, it will auto-increment in every site with a different id. The extension author will have no idea what id the custom field has on any particular site, so the only way to reliably refer to the field is by name. Hope that helps.
Answers.UserDisplayName: Coleman
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-16T15:10:43.287Z
Answers.Text: Thank you, I just wanted to say the way it's designed now is not quite user-friendly, that's all.
Answers.UserDisplayName: yurg
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-14T19:13:33.810Z
Answers.LastActivityDate: 2024-02-14T21:19:23.820Z
Answers.LastEditDate: 2024-02-14T21:19:23.820Z
Answers.UserDisplayName: Coleman
Body: <p>What is API4 analogue of API3  <code>&quot;return&quot;: [&quot;custom_666&quot;],</code></p>
  <p>The below doesn't work:</p>
  <ul>
  <li><code>CRM.api4('Contact', 'get', {select: [&quot;contact_type&quot;, &quot;custom.666&quot;],</code></li>
  <li><code>CRM.api4('Contact', 'get', {  select: [&quot;contact_type&quot;, &quot;custom_666&quot;],</code></li>
  </ul>
  <p><code>select: [&quot;contact_type&quot;, &quot;custom.*&quot;],</code> returns a list of <strong>machine field group.machine field name</strong> which is a bit tricky to search through in the Explorer, since there are some 200 of the and because long strings are being cut off by API4 explorer so sometimes it is only a part of <strong>custom group machine name</strong> is visible.</p>
  <p>Wouldn't be nice to put a field ID at a 1st place, so it is not <code>&quot;Individual_Informations_g_n_rates.Adhesion_suspend_demand_d_infos_compliment_&quot;</code></p>
  <p>but rather</p>
  <p><code>&quot;[666]Individual_Informations_g_n_rates.Adhesion_suspend_demand_d_infos_compliment_&quot;</code><br />
  ?</p>
  
Tags: <api4>
Title: API4 - get a custom field by its ID?
ThreadText: # API4 - get a custom field by its ID?
  
  (Asked by: username_0 on 2024-02-14)
  
  What is API4 analogue of API3 `"return": ["custom_666"],`
  
  The below doesn't work:
  
  * `CRM.api4('Contact', 'get', {select: ["contact_type", "custom.666"],`
  * `CRM.api4('Contact', 'get', { select: ["contact_type", "custom_666"],`
  
  `select: ["contact_type", "custom.*"],` returns a list of **machine field group.machine field name** which is a bit tricky to search through in the Explorer, since there are some 200 of the and because long strings are being cut off by API4 explorer so sometimes it is only a part of **custom group machine name** is visible.
  
  Wouldn't be nice to put a field ID at a 1st place, so it is not `"Individual_Informations_g_n_rates.Adhesion_suspend_demand_d_infos_compliment_"`
  
  but rather
  
  `"[666]Individual_Informations_g_n_rates.Adhesion_suspend_demand_d_infos_compliment_"`  
  ?
  
  **Tags:** api4
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2024-02-14. Score: 3 | Accepted answer
  
  For portability reasons, APIv4 does not use the "custom_id" identifier but instead uses "CustomGroupName.CustomFieldName" as the field key.
  This is because when you migrate one site to another auto-increment ids in the database (including ids of custom fields) are not guaranteed to be consistent.
  
  Wouldn't be nice to put a field ID at a 1st place
  
  No, that would not be portable as the name would include field id. Names can be relied upon as stable between different sites, ids cannot. It's also not human-readable (unless you have memorized the ids of all 666 of your custom fields, the number is meaningless and makes your code hard to understand).
  To directly answer your question, the analogue of this:
  civicrm_api3('Contact', 'get', [
    'return' => ['custom_123'],
  ]) ;
  
  Is this:
  civicrm_api4('Contact', 'get', [
    'select' => ['CustomGroupName.CustomFieldName'],
  ]);
  
  You can also conveniently return all values from a custom group (not possible in api3) like this:
  civicrm_api4('Contact', 'get', [
    'select' => ['CustomGroupName.*'],
  ]);
  
  > **Comments:**
  > **username_0**: Thank you, I trust the decision of using text labels instead of IDs has been made by the high priests aiming to benefit all of us and is not reversible. A few more notes if I may: a). I fail to see how IDs interferes while site migration - normally we append new fields/field groups to an existing ones and that's it, don't we? b). Why would we memorize ID if it is right in the 1st column of the "Custom Data/Custom Data Fields" page table? c) How would you effectively  work with the API Explorer when you can see only a part of a Custom Group (not a Custom Field) label in the select?  
  > **username_1**: We don't have any priests, but we do have a lot of community-contribued extensions - when an extension wants to add a custom field, it will auto-increment in every site with a different id. The extension author will have no idea what id the custom field has on any particular site, so the only way to reliably refer to the field is by name. Hope that helps.  
  > **username_0**: Thank you, I just wanted to say the way it's designed now is not quite user-friendly, that's all.  
  
  ---
  
  