This is where we announce new releases on JourneyApps.
You can subscribe for updates by clicking the button on the top right.
For older release notes, please go here.
We have implemented request rate limits to our backend APIs to further improve our backend performance, and protect against malicious actors from denying backend service to our customers. This notice describes our implementation of rate limiting, and describes when rate limits will be enabled for your app.
Rate limits restrict the number of successful requests against an API endpoint when the endpoint is abused or unintentionally hit unusually hard by an API client.
We are implementing rate limits with the following characteristics:
If the failure of any single request in an API broker or CloudCode task may break data integrity, you will need to update the broker to handle the 429 error response. We recommend that you see whether your API broker or CloudCode tasks could be impacted.
To handle the 429 response, you can implement the following logic where response errors are handled:
“If the response is 429, wait for at 1 second before retrying.”
Here is an example of the JSON response when an endpoint is rate-limited:
"title": "Too Many Requests.",
"detail": "Request rate limit exceeded for this account. Try again later.",
"retry_after": 60 // in seconds, a friendly suggestion
There is no API endpoint that provides this information, so you will have to review your logs to track your usage. Our request limits are based on a one-second rolling window, so a pause of 1 second in the event of a 429 response should suffice in most cases.
As of January 2020, we have started returning a warning to API requests that exceed the rate limit.
You can see the API rate limits applied to a deployment on the Manage API page on the backend Data Browser.
Please take note:
Please contact JourneyApps Support for questions, raising limits, or extensions.
The capture-coordinates UI component (as well as the gps component in v3 syntax apps) uses a Mapbox static tiles API that has been deprecated and stopped working recently. Customers running v3 and v4 apps prior to v4.74 will be impacted as detailed below. Runtime versions newer than v4.74 use the new supported API.
Please update any apps relying on rendering the maps with a newer Runtime version.
The behavior will be similar to when the user is offline, but blank white squares will be rendered instead of the map:
GPS coordinate capturing itself is unaffected; only the map rendering is affected.
One option is to just hide the map, using: hide-if = "true"
It's best to upgrade now to a managed runtime version. Alternatively, use the hide-if workaround above.
V3 containers are affected in the same way, and no update will be released. See the hide-if workaround above.
We're happy to announce that v4.76 of the JourneyApps Runtime has been released. You can use this version of the runtime by selecting it from the list of stable runtime versions under App Settings/Version Management.
This release includes all the fixes for v4.75 and the following:
We're happy to announce that v20.10.2 of the JourneyApps Container has been released.
This release increases the Android API level to meet Google Play Store minimum version requirements.
We've made no changes to functionality.
This is a release which contains the following fixes:
An issue where a radio button's circle shrinks when it the option has a lot of text.
<var name="contact_methods" type="multiple-choice"/>
<multiple-choice-checklist label="Alt syntax" bind="contact_methods3" on-change="$:optionChange($value)">
<var name="contact_method" type="text"/>
<single-choice-radio bind="contact_method" label="Select you preferred contact method">
This release includes all the fixes for v4.74.x and the following:
We're happy to announce that v20.10.1 of the JourneyApps Container has been released.