Conversation
| private function generateAuth(string $timestamp): string{ | ||
| return hash_hmac('sha256', $timestamp, $this->display_key) ?: ''; | ||
| private function generateAuth(string $json, string $timestamp): string{ | ||
| return hash_hmac('sha256', $json.$timestamp, $this->display_key) ?: ''; |
There was a problem hiding this comment.
Now channel has an inbound endpoint, need to include body in auth hash
| name: version | ||
| type: string | ||
| required: true | ||
| required: false |
There was a problem hiding this comment.
The param is not required. Also, this was a breaking change so should have been a major release
There was a problem hiding this comment.
I think we can leave as required, as this is the v3 docs, and if someone doesn't send a version param, they're implicitly accessing v2 for some endpoints (i.e. endpoints that only have v2) and v1 for others.
It also means we can set version as required on the new enquiry endpoint as that's new so we can require up front - even though its only introduced on v3, it's good hygeine as when we eventually bring out a v4 there will be a clear explicit difference between v3 and v4 in the query string
There was a problem hiding this comment.
In the SDK, again given we're tagging this v3, we can default the value to this version as a string
| type: string | ||
| description: | | ||
| ID for the organisation this account belongs to on the StuRents website | ||
| inbound_data_enabled: |
There was a problem hiding this comment.
I'd suggest we are specific about enquiries - given inbound data could be mistaken for the other inbound features our API has like creating properties or creating availabilities. So we could call it enquiry_sending?
M1ke
left a comment
M1ke
left a comment
There was a problem hiding this comment.
Couple of points re field names and version but all v minor
2 participants
No description provided.