Repository navigation
type does not allow custom fields #662
Description
no matter v1 or v2, the payload types defined don't allow for custom fields. it forces us to cast as any to be able to use it, making the value of typescript void. custom fields are a huge part of pipedrive so it's really inconvenient that we can't use them properly.
In hope for a faster path of remediation, I've doodled some type utilities which may achieve custom fields at quite low cost. Here below with comments:
// From https://skalt.github.io/projects/brzozowski_ts/
type HexChar = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a" | "b" | "c" | "d" | "e" | "f";
type IsHex<Str extends string> =
Str extends ""
? true
: Str extends `${HexChar}${infer Rest}`
? IsHex<Rest>
: never;
// From https://stackoverflow.com/a/73369825
type StringLength<Str extends string, Acc extends 0[] = []> =
Str extends `${string}${infer $Rest}`
? StringLength<$Rest, [...Acc, 0]>
: Acc["length"];
type IsLength<S extends string, Length extends number> = StringLength<S> extends Length ? true : false
// A custom field id is 40 char hex string
type CustomFieldId<T extends string> =
IsHex<T> extends true
? IsLength<T, 40> extends true
? string
: never
: never
type WithCustomFields<T, BaseType> = {
[Key in keyof T]:
Key extends string
? Key extends keyof T
? Value[Key]
: CustomFieldId<Key>
: never
}
// --- Example implementation
export type AddOrganizationRequest = {
'name'?: string;
'owner_id'?: number;
'add_time'?: string;
'update_time'?: string;
}
// We let arg be broader than AddOrganizationRequest by defining it as extends and pass the basic blueprint as K. This allow to compare and keep types of BaseType untouched and iterate on T and allow extension if some keyof T are CustomFieldId
function test<T extends BaseType, BaseType = AddOrganizationRequest>(arg: WithCustomFields<T, BaseType>) {}
test({
name: 'foo',
owner_id: 0,
add_time: 'foo',
update_time: 'foo',
['deadbeefdeadbeefdeadbeefdeadbeefdeadbeef']: 'foo', // allowed
})
test({
name: 'foo',
owner_id: 0,
add_time: 'foo',
update_time: 'foo',
['qwe']: 'foo', // denied
['deadbeefdeadbeefdeadbeefdeadbeefdeadbeef']: 'foo', // allowed
})
test({
name: 'foo',
owner_id: 0,
add_time: 'foo',
update_time: 'foo',
['qwe']: 'foo', // denied
})
Activity
youssef-saber-3 commentedon Sep 3, 2025
Hey , thank you for reporting this issue, we've added the
custom_fieldsdefinition to the create organisation request , it should be fixed in this versionyoussef-saber-3 commentedon Sep 3, 2025
and just to confirm @y-nk , you're importing from the v2 namespace, right ?
y-nk commentedon Sep 3, 2025
@youssef-saber-3 import is
import { v1, v2 } from 'pipedrive'it's a more general issue. we have this issue everywhere basically. in every single payload such as "create person", "create lead" etc etc etc.
EDIT: it's quite mysterious that the package is rebuilt but there's nothing in the changelog :(
youssef-saber-3 commentedon Sep 3, 2025
The changelog item should be this one "Documented the custom_fields in /v2 api for create organization and update deal"
essentially the issue comes from the opanapi yaml file , if the custom_fields isn't documented there then it doesn't end up in the generated sdk, i'll take a look at those individual cases like "create person" and "create lead" and fix them if they support passing the custom fields to the api, feel free to mention any other entities you have issues with , I'll re-open this issue for visibility
y-nk commentedon Sep 3, 2025
i have checked the types and only the v2 is covered. there's a
custom_fieldsobject in the payload, which i guess is a breaking change from the v1. v1 tho is not fixed, types still don't support custom fields.youssef-saber-3 commentedon Sep 16, 2025
Hey @y-nk i looked into it and the v1 behavior is slightly different , it takes the custom fields in the root of the object like the following , i've fixed it in the latest version 29.2.3 and will update the docs shortly to reflect the difference between v1 and v2
y-nk commentedon Sep 16, 2025
@youssef-saber-3 i'd be concerned that, since custom fields is
Record<string, string>adding them to the root object will mess up and allow any kind of keys to be provided, as any string key would be considered valid custom fieldscyrill-kohler commentedon Feb 10, 2026
@youssef-saber-3
custom_fields props are missing on Person in v1 and v2 as of version 31.2.9.
github-actions commentedon Jul 12, 2026
This issue has been marked as stale due to inactivity. It will be closed in 30 days if no further activity occurs.
y-nk commentedon Jul 13, 2026
@youssef-saber-3 any update?