API change log
2.0.0-pre
First v2 preview — major consolidation and new features.
Open source
- Open Pryv.io v2 is now fully open source under BSD-3-Clause. The former “Enterprise version” and Open Pryv.io are now the same codebase.
- Docker image published as
pryvio/open-pryv.io(waspryvio/corefor v1). Pullpryvio/open-pryv.io:2.0.0-pre.
Consolidated runtime
- Registration, MFA, high-frequency series and previews are now served by a single binary (
bin/master.js), replacing the previous per-service Docker images (pryvio/core,pryvio/hfs,pryvio/preview,service-register,service-mfa). - Cluster mode: configurable N API workers + M HFS workers + optional previews worker under one master process.
- High-frequency series endpoints (
/{user}/events/{id}/series,/{user}/series/batch) are reachable on the same public port as the rest of the API — an in-process dispatcher routes them to the HFS worker on:4000. Setcluster.hfsWorkers: 1(or more) to enable HFS; no external reverse proxy required. For high-throughput installs, front the cluster with nginx (reference vhost:docs/nginx-ingress-sample.conf). SDKs readfeatures.noHFon/service/infoto know whether HFS is served — auto-derived fromcluster.hfsWorkers.
Multi-factor authentication (ported from the former Enterprise version)
- New API:
mfa.activate,mfa.confirm,mfa.challenge,mfa.verify,mfa.deactivate,mfa.recover. - When a user has MFA active,
auth.loginreturns{ mfaToken }instead of a regular access token. Clients must follow up withmfa.verify(SMS code) to obtain the Pryv access token. - Back-office
system.deactivateMfaremains available alongside the user-facingmfa.deactivate. - Disabled by default (
services.mfa.mode: disabled) — existing deployments see no change.
Registration merged into core (was service-register)
- All
/reg/*endpoints are now served by the main binary. No separate register service to deploy. - Backing store is PlatformDB (rqlite) — replaces the previous redis/leveldb storage.
- Legacy routes, invitations, DNS-less registration and multi-core indirection are all preserved.
Multi-core deployments
- Per-user routes (
/:username/*) enforce core affinity. Cross-core requests receive HTTP 421 Misdirected Request with body{ error: { id: 'wrong-core', message, coreUrl } }— clients must retry directly againstcoreUrl. No HTTP redirect is issued (cross-origin redirects stripAuthorizationheaders, WebSockets cannot follow). /reg/*and/system/*remain load-balanceable.- New
core.urlper-core config override for DNSless multi-core deployments where FQDNs cannot be derived from{core.id}.{dns.domain}. Other cores discover the URL viaPlatform.coreIdToUrl()(PlatformDB-backed).
Storage
- PostgreSQL backend (optional): full MongoDB parity for events, streams, accounts. Select via
storages.engines.*config. Note: v1→v2 data migration currently only operates from a MongoDB v1 source; migration into a PostgreSQL v2 backend is not yet supported. See INSTALL.md. - rqlite is now the only platform-storage engine — the legacy sqlite platform store was removed.
master.jsalways spawnsrqlited.
Upgrading from v1
- Toolkit at
dev-migrate-v1-v2: exports v1 user data (MongoDB) and produces a v2-compatible backup directory thatbin/backup.js --restorecan import.
Access versioning (Plan 66)
accesses.updateis back (was removed in early v2).PUT /accesses/{id}mutates the head, snapshots the prior state into history, and bumps the access’sserial. Mutable fields:name,deviceName,permissions,expireAfter/expires,clientData. See Update access.- New
GET /accesses/{id}(Get one access) accepting either bare<base>or composite<base>:<serial>ids. Composite with an older serial returns the historical snapshot + acurrenthint. Pass?includeHistory=truefor the full version history. - Composite-id wire format:
access.id/access.createdBy/access.modifiedBynow serialise as<base>:<serial>once an access has been updated at least once. Never-updated accesses still serialise as bare cuid — fully backwards-compatible. Usepryv.utils.parseAccessRef(lib-js ≥ 3.1.0) to extract{ base, serial }. - Composite-id conflict:
accesses.updateandaccesses.deleterequire the caller’s{id}to match the current head’s serial. A stale composite returns409 stale-resourcewithdata: { provided, currentSerial }; refetch and retry. - New socket.io event
accessUpdatedfired after every successfulaccesses.update, alongside the existing coarse-grainedaccessesChanged. Payload:{ type: 'access-updated', accessId: '<base>:<serial>', serial }. - Chain rules: shared-access permissions must remain a subset of their managing app; narrowing a parent rejects with
offendingChildrenif any managed child would be orphaned. Expiry chain enforced on bothaccesses.updateAND retrofitted onaccesses.create(breaking if you previously created shared accesses with longer expiry than the parent app).
Known gaps in 2.0.0-pre
- OAuth2 authorization-code flow (RFC 6749
/oauth2/authorize,/oauth2/token, client registration, refresh tokens, PKCE) is not in this preview. Clients that need OAuth2-style authorization must continue using the existing/reg/accesspolling flow (now core-affinity aware in multi-core deployments).
1.9.3
- Added Audit from Entreprise version to Open-Pryv.io.
1.9.2
- Refactored Attachments (Event Files) Logic to be modular for future cloud storage of files such as S3.
1.9.1
- Implemented ferretDB compatibility allowing full-open source modules
- Replaced rec.la by backloop.dev
1.9.0
Many under-the-hood changes and a couple fixes, including:
- Stream response to
streams.deletemethod to avoid potential timeout - Deleted stream ids are now already reusable when following the auth process
- Username is not available anymore form
usernamesystem stream. It should be retreived fromaccess-info.
1.8.1
Fixes migration issue when upgrading from 1.6.x to 1.8.0
1.8.0
New features:
- Password policy support: rules for password complexity (length, character categories), age (minimum, maximum i.e. expiration) and reuse (i.e. history) can be enabled in the platform settings under ‘Advanced API settings’
- External data stores support (a.k.a. dynamic mapping, or personal data mapping); enterprise users please contact us for the details.
1.7.14
- Fixes two issues with
selfRevokepermissions, one of which related to the system streams backward compatibility flag; the issues caused a crash and prevented creation of accesses withselfRevokepermissions.
1.7.13
- Fixes for miscellaneous issues, including issues with the system streams backward compatibility flag (
BACKWARD_COMPATIBILITY_SYSTEM_STREAMS_PREFIX), occasionally sluggish performance when querying events by type, and an occasional failure to restart services after a configuration change.
1.7.10
- API change: Don’t coerce the event content values according to type
- Fixes: Allow event types validation for array
1.7.9
- Security fix: make password reset token single-use
1.7.0
Changes:
- Audit has been re-implemented, offering improved performance:
- See the Audit logs guide for API usage
- Audit logs are now available through the Events API, deprecating the previous route and its data structure
- System streams have been modified. Their prefix changes from
.(dot) to:_system:&:system:. See the System streams page for details. - Tags have been removed from Events. In Pryv.io platforms that contained them, they are migrated to streams, See
BACKWARD_COMPATIBILITY_TAGSplatform parameter in your platform configuration. The tags functionality is ensured by Streams queries for the events.get API method. - Permission levels are computed differently: If a child stream has a different permission than a parent, its level is indeed applied on the child (instead of the higher permission taking precendence as was done before).
- Integrity hash is computed for Events, Attachments and Accesses. This functionality can be disabled.
- Automated platform migration using the migrations.get and migrations.apply API methods.
1.6.20
New routes:
- Deactivate MFA for admin API, for when the user has lost his 2nd factor.
1.6.19
New routes:
- Get core API method that returns the hostname of the core on which a certain user data is stored.
1.6.7
New Features:
Removals:
- Deprecated “GET /who-am-i” API method removed
- Remove pryvuser-cli, as it is now available through the admin API
1.6.2
Changes:
- Custom auth function has now access to all request headers. See custom authentication guide.
1.6.1
Changes:
- increase JSON input payload to 10MB for HF server. See Data format.
v1.6.0
New features:
- System streams:
- Customizable unique and indexed properties for registration
- Account data accessible through Events API
- More details on System streams
- Admin API:
- Edit platform parameters
- Manage platform users
- More details on Admin reference
- Admin Panel:
- Web application for entreprise Pryv.io platform administration
Changes:
- New registration flow, more details on Account creation
Deprecated:
- Old registration flow
v1.5.22
Changes:
- Deleting an app token deletes the shared accesses that were generated from it (if any).
v1.5.18
New Features:
- Call ‘GET /access-info’ now returns the username to avoid having to extract it manually from
pryvApiEndpoint.
Changes:
- Call ‘POST /user’ (create user) on register. The property
serveris now deprecated in favor ofapiEnpoint.
v1.5.8
New Features:
- Socket.io v2
Removals:
- Socket.io v0.9
v1.5.6
Changes:
- Webhooks API routes now available for
sharedaccesses. - Socket.io interface availablel for
sharedaccesses. - Socket.io interface availablel for accesses with
create-onlypermissions.
v1.5.5
New feature:
- Access permission
{ "feature": "selfRevoke", "setting": "forbidden"}, more details on Access data structure.
v1.5
New Features:
- Events can now be part of multiple streamIds
authUrlreplacesurlin Auth request in-progress responsepryvApiEndpointreplacesusernameandtokenin Auth request accepted responseaccesses.deletehas been extended for self revocation tosharedandappaccesses
Deprecated:
event.streamId: replaced byevent.streamIdsevent.tags: their functionality will soon be totally replaced by streamIdsurlin Auth request in-progress responseusernameandtokenin Auth request accepted response
Removals:
- Timetracking functionalities have been removed
- singleActivity streams are now standard streams
events.startevents.stop
accesses.update
V1.4
New features:
- Auth request now accepts a custom
serviceInfoobject, which is returned by the polling url. In case of success, apryvApiEndpointfield is returned. See Auth request for more details. - Add
create-onlypermission level. See the Access data structure for more details. - Add multi-factor authentication for login using the optional MFA service. See the MFA API methods for more details.
- Add auditing capabilities through the Audit API. See the Audit API methods for more details.
- Pryv.io API now supports the Basic HTTP Authorization scheme.
- Release of webhooks to notify of data changes. See Webhook data structure and methods for more details.
- Add route
/service/infothat provides a unified way for third party services to access the necessary information related to a Pryv.io platform. See description for more details. - Most API calls now present a
Pryv-Access-Idresponse header that contains the id of the access used for the call. This is the case only when a valid authorization token has been provided during the request (even if the token is expired). See metadata for more details.
Changes:
- Enrich access-info result with exhaustive access properties.
- Improve the update account API call, in particular when it applies a change of email address. It now correctly checks if the email address is not already in use before updating the account and throws consistent errors.
Deprecated:
- Timetracking functionalities
- singleActivity streams
- events.start
- events.stop
V1.3
New features:
- High Frequency events allow storing data at high frequency and high data density. Create them by using types that start with
series:X, where X is a normal Pryv type. The API also supports inputting data into multiple series at once, this is called a ‘seriesBatch’ (POST/series/batch). - Add
clientDatafield to Accesses. - Add
httpOnlyflag to server-side cookie sent in response to successful/auth/loginrequest. - Deleted accesses can now be retrieved. See accesses.get method for more details.
- Accesses can now be made to expire. See the access data structure documentation for more details.
Changes:
- Some invalid requests that used to return a HTTP status code of 401 (Unauthorized) now return a 403 (Forbidden). Only the requests that are missing some form of authentication will return a 401 code.
updates.ignoreProtectedFieldsis now off by default. This means that updates that address protected fields will result in an error being returned.
v1.2
Changes:
- Fix login with Firefox (and other browsers using Referer but no Origin).
- Security fix 2018020801: ‘accesses.update’ was missing an authorisation check.
- Update of the API version in API responses.
- Fix events.get JSON formatting.
- Add configuration options to disable resetPassword and welcome emails.
- Add configuration option to ignore updates of read-only fields.
- Tags have a maximum length of 500 characters. An error is returned from the API when this limit is exceeded.
v1.1.8
Changes:
- Fix edge-case behaviour on very large
streams.deleteoperations. - Direct
events.getAPI call now supports really large results. Changes made have improved this call’s performance by around 30%. As a by-product of this change, we now do not send the ‘Content-Size’ HTTP header anymore. - Allow custom cuid-like ids when creating events.
v1.1
New feature:
- Versioning:
- a new endpoint on
/events/{id}allows to retrieve a specific event by hisid. Setting theincludeHistoryparameter totrue, the response will contain an array of the previous versions of the event in thehistoryfield.
- a new endpoint on
v1.0
Validated initial set of API features.
v0.8
Changes:
- Deletion methods now:
- Reply to permanent deletions with a
{item}Deletionfield confirming the deleted item’s identifier. - Always return code 200 on HTTP (that’s a rollback of the v0.7.x change which was a bit too zealous to be practical).
- Reply to permanent deletions with a
New features:
- Event and stream deletions are now kept for sync purposes; they’re accessible via parameter
includeDeletions(events.get) orincludeDeletionsSince(streams.get). Deletions are cleaned up after some time (currently a year).
v0.7
Major changes here towards more standardization and flexibility:
- All JSON responses (both in HTTP and Socket.IO) are now structured as follows:
{ "{resource}": {...} }if a single resource item is expected; for example:{ "event": {...} },{ "error": {...} }{ "{resources}": [ {...}, ... ] }if an indeterminate number of items is expected; for example:{ "events": [ {...}, ... ] }
- All responses to resource creation and update calls now include the full object instead of respectively its id and nothing; for example:
{ "stream": {...} } - All JSON responses now include
meta.apiVersionandmeta.serverTimeproperties mirroring the originalAPI-VersionandServer-TimeHTTP headers; HTTP headerAPI-Versionremains - Deleting a resource now returns code 204 if the item was permanently deleted; it still returns a 200 when trashed (now including the trashed item in the response)
- Method ids for deletion/trashing are now
{resource}.deleteinstead of{resource}.del - The
attachmentsproperty of events is now an array (instead of an object), with each attachment now identified by a newidproperty (instead offileName) - As a security measure, reading attached files now either requires auth via the
AuthorizationHTTP header or a newreadTokenquery string parameter (authisn’t allowed anymore in this case); the token to use is specific to each file and access, and is defined in thereadTokenproperty of each event attachment - Event batch creation method has been replaced with generic batch method (
callBatch, HTTP:POST /) - Bookmarks have been renamed to “followed slices”, corresponding method ids to
followedSlices.*and HTTP routes to/followed-slices - Getting events: setting the
tagsparameter now returns events with any of the specified tags, instead of all of them - Error ids:
unknown-*errors replaced with eitherunknown-resourceorunknown-referenced-resourceitem-*-already-existsreplaced withitem-already-existsmissing-parameterreplaced withinvalid-parameters-format
- Other improvements and fixes (data validation performance, minor bugs on auth for trusted apps)
New features:
- Getting events: filter for specific event types with the
typesparameter - Accesses can now define tag permissions in
permissions(in addition to the existing stream permissions)- If only tag permissions are set, all streams are considered readable, and vice-versa
- When stream and tag permissions conflict, the highest permission level is considered
- Full support for managing account information, including password change and reset
v0.6
Changes to HTTP paths and auth for trusted apps:
- Get streams: removed
trashedoption forstateas it was more trouble than anything useful - Accesses now includes property
id(exposed for referencing)- Create access response now includes both
idandtokenproperties - For existing accesses,
idandtokenare equal
- Create access response now includes both
- Events, streams and accesses now includes change tracking properties:
createdandmodified(timestamp)createdByandmodifiedBy(access id or"system")
- Socket.IO method calls now directly use method ids (e.g.
events.createand pass method params, instead of usingcommandand passing an object with method id and params - For trusted apps only: removed the distinction between “admin” methods and others; breaking changes
/admin/login,/admin/logoutand/admin/who-am-imoved to/auth/login,/auth/logoutand/auth/who-am-irespectivelysessionIDrenamed totokenin login response and SSO cookie data- Personal accesses are now automatically created on login; they can’t be created explicitly anymore
/admin/user-infomoved to/user-info/admin/accessesmerged into/accesses/admin/bookmarksmoved to/bookmarks/admin/profilemerged into/profile
v0.5
This is a major update that will break most libs and clients, which should be updated ASAP.
- Simplified the API by removing channels and renamed folders into “streams”; adjusted the structure of accesses, streams and events accordingly; more details:
- As a consequence, every event now belongs to a stream
- Data migration: former channels will be converted into root-level streams, and former folders into sub-streams of those
- Events structure:
event.typeis now a string of format{class}/{format}(e.g.picture/attached) instead of an object withclassandformatpropertiesevent.valuehas been renamed toevent.content
- Get events:
- Renamed parameter
onlyFoldersto juststreams - Added
runningboolean parameter, replacing “get running periods” method
- Renamed parameter
- Removed “get running periods” (i.e.
GET /events/running, see above) - Removed
hiddenproperty of streams (ex-folders), which was mostly unused and out of place
v0.4
- New feature: Allow HTTP method overriding by POSTing _method, _json, and _auth parameters in an URL-encoded request
- Improvement: Retrieving events for a specific timeframe now includes all events that overlap that timeframe, including period events that started earlier
- Added event type validation: the API will now check if an event being created or updated has a known type (as listed on our event types directory), and if yes perform data validation on its value (returning a 400 error if invalid)
- All error ids have been changed to use
slug-styleinstead ofC_CONSTANT_STYLE(so that e.g.INVALID_PARAMETERS_FORMATis nowinvalid-parameters-format); this is consistent with the other ids we’re using in the system
Earlier
Versions earlier than v0.4 are not covered here.