Mixed JSON property naming strategy

Sure there are lots of inconsistencies. It looks like these changes are introduced over time and you don’t want to break existing apps. That also why an itemId is still called a pulseId in the events. That’s from the time monday.com was called daPulse 🙂

It doesn’t look that they will change this and we as developers has to live with it.

Hello everyone!

Thank you for sharing your thoughts about this.

I will share this feedback with our R&D team and add a +1 for @basdebruin.

Cheers,
Matias

@basdebruin I appreciate the response and I understand this. With all of the respect though there is a difference when it comes to maintaining an integration contract versus making it difficult to work with it. I’ll give you another example.

When we get create web hook event the id is referred to as pulseId while when we get back an archive event we get back an itemId.

I understand the reasoning for this, but you either make consistent changes across your APIs or you introduce aliases BUT never break consistency as it makes it extremely difficult to work with.

I can’t complain, the API and webhook calls has been extremely helpful for our use cases but these small details end up taking time having to figure out why specific things don’t work. So yes +1 on backwards compatibility but again, use aliases or the least common JSON format within the same document. Honestly at this point I doubt that is possible to change it unless you introduce a v3 of it. You can definitely though add aliases on your documents so that you can support both items and pulseId and issue a sunset day on your next major version release

hi @kallikakis

Fully agree that we are at a point where an V3 API is needed. Some of the current inconsistencies can be somewhat explained if you know the history, still there are lots of others (column type names as an example “status <> color”, number <> numeric"). You would also kind of expect (or at least hope) that the format of a (previous) value returned by a webhook can be used unmodified as a value to update an item / column through the API.

@basdebruin

I’m tempted to be a little “snarky”. But I’ll be nice…

Getting those “little things” fixed/cleaned up would be quite helpfu! I especially agree with:

To add to the story of inconsistency: using both create_subitem and subitem_deleted, what do you think the event shows for the ID.

QUIZ: does it send event.pulseId or event.itemId?

CONGRATS: you are the winner of this quiz (because both are correct)

create_subitem sends event.pulseId
subitem_deleted sends event.itemId

@Matias.Monday is this an effort from monday to make is as difficult as possible for developers to develop apps?

It gets even uglier…

@JsonProperty("pulseName")
@JsonAlias("itemName")
private String pulseName;
...
@JsonProperty("pulseId")
@JsonAlias("itemId")
private Long pulseId;

My code is everywhere with double mappings as well as

On the parent class something like

@JsonNaming(PropertyNamingStrategies.LowerCamelCaseStrategy.class)

While on nested objects

@JsonNaming(PropertyNamingStrategies.SnakeCaseStrategy.class)

It took me some time trying to figure out why things are not working as it should

Concur, a v3 thats a fresh start would be great, along with that an enhanced apps platform which lets us define apps in code, aws-cdk style. Ideally with that, a series of epics related quality and craftsmanship in general. Polish, polish, polish - will pay off by making future feature development much easier.

Hello all,

Thank you for your feedback!

I have shared all of this with our API team.

Cheers,
Matias

Hi all, especial @kallikakis and @basdebruin

Just wanted to update
That we aligned all our API for webhook event for create_subitem, delete_subitem, archive_subitem and now both of them returning itemId and pulseId when event is triggered

hi @Yoni_Leivn

That is good news. Are the delete and archive subitem events also sending the itemIdParent and boardIdParent (as the crate and change events do)? Without knowing where the item was deleted / archived from it is hard to develop apps with full support for subitems.

@basdebruin
It’s already part of create_subitem event:
Now they are part of event as well:
event: {
userId: 1,
originalTriggerUuid: null,
boardId: 118607865,
pulseId: 118607981,
pulseName: ‘sasa’,
groupId: ‘group_title’,
groupName: ‘Group Title’,
groupColor: ‘#a25ddc’,
isTopGroup: false,
columnValues: {},
app: ‘monday’,
type: ‘create_pulse’,
triggerTime: ‘2022-07-20T10:02:35.132Z’,
subscriptionId: 202,
triggerUuid: ‘a74c99db1cf790be304f43f053776828’,
parentItemId: ‘118607594’,
** parentItemBoardId: ‘118607592’,**
itemId: 118607981
}
}

For archive & delete, I will add it to our roadmap and try to address it in upcoming weeks.

Hi @basdebruin
Just wanted to notify that parentBoardId and parentItemId were added to subitem_deleted and subitem_archived events for webhook.

subitem_archived

event: {
    userId: 6530990,
    originalTriggerUuid: null,
    boardId: 1854488565,
    itemId: 2982703056,
    itemName: 'Batman',
    parentBoardId: 1721464578,
    parentItemId: 2982701371,
    app: 'monday',
    type: 'archive_pulse',
    triggerTime: '2022-08-02T10:38:51.115Z',
    subscriptionId: 144369200,
    triggerUuid: 'c5bafec2157ec451aa071bccbfa4be05',
    pulseId: 2982703056
  }

subitem_deleted:

event: {
    userId: XXXXXXXX,
    originalTriggerUuid: null,
    boardId: 1854488565,
    itemId: 2982702998,
    itemName: 'Superman',
    parentBoardId: 1721464578,
    parentItemId: 2982701371,
    app: 'monday',
    type: 'delete_pulse',
    triggerTime: '2022-08-02T10:38:40.350Z',
    subscriptionId: 144369290,
    triggerUuid: '6b478c6ee5b4d0955a2017f60c6c0540',
    pulseId: 2982702998
  }

hi @Yoni_Leivn

That is wonderful. One little thing that costs me a few hours to find out.
create_subitem and change_subitem_column_value send (among others)
parentItemBoardId
parentItemId

With this update subitem_archived and subitem_deleted send (among others)
parentBoardId
parentItemId

Why is it so hard to be consequent? See: parentItemBoardId vs. parentBoardId