API & Code Change Log

Now that we are wrapping up our performance environment upgrades, part of our focus is shifting towards improving our API and live app code.

We’re creating this topic to log any changes we make. We’ll likely move to a more formal change log in the future, but this gives us a space in the meantime to post and discuss changes.

Don’t worry, we’ll still broadly announce any major changes. But we also wanted an easy channel to post about minor changes as well.

9 Likes

First up: we are changing how we respond to invalid API request keys, like field or object keys. Requests with invalid keys will now consistently respond with HTTP status code 400.

Previously, some routes would return a 200 HTTP status code and a “normal” JSON response body, depending on what the request was doing.

For example, a request to fetch records for an object would return a JSON response body with attributes such as total_records: 0, records: [], even if an invalid object key was provided.

Now the response body will be a string containing a basic validation error (e.g., Invalid Object Key).

Note that an invalid key is anything not properly formed. For example, ‘object_1’ is a properly formed key for objects (even if it does not exist), but ‘invalidkey’ is not.

Our plan is to release this Monday, September 19th.

4 Likes

Thanks for sharing the update :+1:

Great!! Thank you Brandon.

Good news.
Thanks for the update @Brandon.

Hi there. We have some code that integrates with Knack via the api and we noticed some errors last week. Turns out that some records are now returning an empty string (not null) for the _raw value of email type fields where there is no email specified. This seems like it will break most json deserialization code so I wanted to check in with you to see if you were aware and if it was an intentional change?