For the v4 webhook journaling endpoints, I am seeking to understand the POST endpoint to create/update a subscription.
When testing the endpoint, if I make subsequent POST requests using the same subscriptionType (example: “OBJECT”) and specify a different subset of actions or different properties, it seemingly will overwrite (update) and previous subscriptions.
Example:
Request A:
POST for “OBJECT” subscriptionType for properties [“firstname”]
> Returns a unique identifier for subscription “id” as 012345678
Request B:
POST for “OBJECT” subscriptionType for properties [“lastname”]
> Returns previous identifier for subscription “id” as 012345678 and removes “firstname” from the trigger properties.
So when calling this endpoint can there only be one subscription per subscriptionType? And each ‘id’ defines a unique subscription solely dependent on subscriptionType?
Thanks
Hey @RLehrhaupt,
Thanks for posting in the Community!
I was reading through that resource, and the documentation doesn’t explicitly state a one-subscription-per-subscriptionType limit. It only describes how to create subscriptions with different subscriptionType values (OBJECT, ASSOCIATION, APP_LIFECYCLE_EVENT, LIST_MEMBERSHIP).
I’d like to tag in a few Community experts to see if they have more thorough insight on your inquiries. @Anton, @alyssamwilie, and @SteveHTM - any thoughts on whether or not there can only be one subscription per subscriptionType? Additionally, does each id define a unique subscription solely dependent on subscription Type?
Shane, Senior Community Moderator
Shane, thanks for reaching out. I should specify that the unique subscription would be per subscriptionType with the corresponding object type combination, not just subscriptionType that I mistakenly suggested before. On my testing when calling the endpoint on successive calls for the same subscriptionType and object combo (at least for OBJECT), the subscription details were overwritten instead of a new one being made.
Given the amount of parameters across all subscription possibilities (which would take a while to test), looking to see if there is a clear definition for how a unique subscription is defined.
Here is what I have gathered from my initial testing, although, I do have some uncertainty about the findings and if there are plans to change behavior in the future:
The identity of a journaling subscription is minimally based on subscriptionType and each subscriptionType may have additional attributes that define its uniqueness and whether subsequent calls overwrite an existing subscription or create a new one.
Attributes for each subscriptionType that define it’s uniqueness (any subsequent calls with these matching attributes in your call will overwrite the existing subscription):
OBJECT
- subscriptionType
- objectTypeId
ASSOCIATION
- subscriptionType
- objectTypeId
LIST_MEMBERSHIP
APP_LIFECYCLE_EVENT
- subscriptionType
- eventTypeId
It looks like for OBJECT and ASSOCIATION there is only one unique subscription per objectTypeId.
The list membership subscription appeared to be unique across all lists (including across all types) - no separate sub for each object type lists. The subscription info actually attaches an objectTypeId that it detects from presumably the first list Id specified, but you can specify list Ids across different object types, so I imagine this is ignored. From my testing, it looks like events for any object type list as long as the id is in listIds will be written to journals. I am not sure how it works with objectIds specified and if it will scope events to those object id values across all object and all lists within the subscription. So the objectIds should encapsulate all object ids across all object types involved with listIds.
Hello @chrisntr, would you be able to confirm this behavior?
Thanks!