We've racked our brains for a bit now, on how we could more intuitively define our Account, Contact and Event payloads. We offer the flexibility of using whatever field you want to identify a record, however we then require 2 parameters, one to specify the API name, and the other to contain the value.
It's way easier if the Key/Value pairs are Field/Value. The snag however is how do we know what field it is the one the requester wants to use as the identifier?
Well here's where the URL path comes in. As part of the endpoint the user tells us the API name that is considered the ID field. Then, they define a nested JSON object with all the field/value mappings. If the one they want to use as the id isn't there... well then they get an error. Here's what the new endpoints will look like:
We've racked our brains for a bit now, on how we could more intuitively define our Account, Contact and Event payloads. We offer the flexibility of using whatever field you want to identify a record, however we then require 2 parameters, one to specify the API name, and the other to contain the value.
It's way easier if the Key/Value pairs are Field/Value. The snag however is how do we know what field it is the one the requester wants to use as the identifier?
Well here's where the URL path comes in. As part of the endpoint the user tells us the API name that is considered the ID field. Then, they define a nested JSON object with all the field/value mappings. If the one they want to use as the id isn't there... well then they get an error. Here's what the new endpoints will look like: