AppsDB is a key/value store for showpad app developers.
It can be accessed by leveraging the JavaScript API from an experience app or by using the REST api which is documented here.
| Functionality | Changes |
|---|---|
| Pull changes | A query parameter "omitDeleted" has been added and can be used to pull only non-deleted entries. Omitting the parameter or setting it to false will result in returning all entries. |
| Push changes | A changed entry's "changedAt" field will now be offset with the server time minus the pushedAt time to correct clock drift. When the changedAt time lands in the future it will be truncated to the current server-time. |
| Push changes | "MultiStatusProblem".resolveAction will return "revert" for a problem with a type "conflict". In this case, a new "currentEntry" field will be populated with the entry that end-user needs to revert to. In other cases, "currentEntry" will be empty. |
| Push changes | "ProblemWithFailedEntry" is renamed to "MultiStatusProblem". "MultiStatusProblem" contains 1 optional field - resolveAction which can be "none" (default), "delete", "revert". Currently it's set to "delete" only for a problem with a type "store-not-found". |
| Get user-scoped entries , Get global entries, Pull changes | Changed query-parameter sinceChangedAt to since. This to reflect the intention of returning the changes known since this time. |
| Pull changes | Changed field untilChangedAt to until. This to reflect the intention of returning the changes known until this time. |
| Push changes | Added functionality to push user-scoped entries. |
| Delete user-scoped entry | Returns a 204 with no response body instead of a 200. |
| Delete global-scoped entry | Returns a 204 with no response body instead of a 200. |
| Push changes | Added deleted property (boolean) to indicate whether an entry has been deleted or not. |
| Pull changes | Entries contain deleted property, only when value is true. |
| Create store, Get user entries, Get user entries for a specific user, Get user entry, Create user entry, Delete user-scoped entry, Get global entries, Get global entry, Create global entry, Delete global-scoped entry, Pull changes, Push changes | "Error" schema has been renamed to "Problem" and contains 2 extra fields, i.e. "type" and "status" |
| Push changes | "MultiError" schema has been renamed to "ProblemWithFailedEntry" and contains 1 extra fields, i.e. "type" |
| Delete user-scoped entry | Returns a 410 when resource is already deleted. |
| Delete global-scoped entry | Returns a 410 when resource is already deleted. |
| Push changes | Added problem type "already-deleted" which corresponds to status code 410 |
| Create store, Get user entries, Get user entries for a specific user, Get user entry, Create user entry, Delete user-scoped entry, Get global entries, Get global entry, Create global entry, Delete global-scoped entry, Pull changes, Push changes | Field "message" on the "Problem" schema has been renamed to title |
| Create user entry, Create global entry, Push changes | All PUT and POST requests with a body now require a "Content-Type" header set to "application/json" |
| Create store, Get user entries, Get user entries for a specific user, Get user entry, Create user entry, Delete user-scoped entry, Get global entries, Get global entry, Create global entry, Delete global-scoped entry, Pull changes, Push changes | Added problem type "throttled" which corresponds to status code 429 |
A store is the top-level object which groups multiple store entries together.
A store must be registered before it can be used. This is done by using a POST request to the store endpoint.
A store entry is the actual object that holds your data. A store entry is identified by an ID and holds a string as value.
Each store entry sits in a Store and has an associated scope.
A scope is the permission boundary from which an entry is accessible.
Currently there are two scopes. USER scope and GLOBAL scope.
When an entry is created in the USER scope that entry is associated with the showpad user that has created that entry.
This means that each user can have its own set of entries within the same store, without colliding with entries from another user.
Even though user entries are scoped to a single user it is possible to retrieve all store entries cross-user by using the store entries call. Note that this call requires an additional OAuth2 scope "appsdb_online_integrations" which can be set to your OAuth2 client or by creating a personal access token.
Entries created within the GLOBAL scope can be retrieved by all users but can only be created when the requester has
the "appsdb_online_integrations" OAuth2 Scope.
AppsDB uses cursor based pagination with an optional limit. When retrieving a large list of user or global scoped entries we limit the amount of entries returned to 1MB or limit(default:1000) amount of entries.
Whenever one of these limits is hit, we return a cursor-string that can be passed to a subsequent request to receive the next page of entries.
When no cursor is returned all entries have been retrieved.
AppsDB is eventual consistent. When you read data from AppsDB, the response might not reflect the results of a recently completed write operation. The response might include some stale data. If you repeat your read request after a short time (usually within a second), the response should return the latest data.