Testimonials
What our customers say about Team Password Manager

API v3: Change log

Current Team Password Manager version: 12.160.277

Changes in API v3 in TPM V6

If you're using v6.x of Team Password Manager you should be aware of the following changes in API v3. Note that API v3 is a deprecated version of the API (it will be discontinued in future versions of Team Password Manager), you'd better use API v4.

In projects:

  • show project:
    • everyone_has_access=TRUE if grant all is set to a value (even if "No access"). If grant all is inherited, this gets the value from the parent.
    • users_access/groups_access array have user/group that is set a permission (even if "No access").
    • user_permission can be "Traverse", "Read", "Read / Create passwords", "Read / Edit passwords data", "Read / Manage passwords" or "Manage".
  • list users who can access a project: access_type can be "No access", "Traverse", "Read", "Read / Create passwords", "Read / Edit passwords data", "Read / Manage passwords" or "Manage".
  • create/update project:
    • if everyone_has_access is set it will set a "Read / Create passwords" permission on the project for all the users (grant all in V6).
    • users/groups in users_access/groups_access will be set "Read / Create passwords" permission on the project (except for read only users that will be set "Read" permission).
    • "managed_by" users can be normal users too (not only users with role IT/Project manager/Admin).
  • delete a project: only leaf projects can be deleted.

In passwords:

  • show password:
    • everyone_has_access=TRUE if grant all is set to a value (even if "No access") in project.
    • users_access/groups_access array have user/group that is set a permission (even if "No access").
    • user_permission can be "Read", "Edit data" or "Manage".
  • list users who can access a password: access_type can be "No access", "Read", "Edit data" or "Manage".
  • create passwords: only users with the following permissions in a project can create passwords in the project: "Read / Create passwords", "Read / Edit passwords data", "Read / Manage passwords" and "Manage".
  • update passwords: users with "Edit data" permission can update the password (not only the ones with "Manage" permission).
  • update security:
    • users/groups in users_access/groups_access will be set "Manage" permission on the password (except for read only users that will be set "Read" permission - that was already being done).
    • "managed_by" can also be any user (except read only users), not just users that have access to the password.
  • update security, update custom fields definitions, delete, lock/unlock: the user making the request needs to have Manage permission.

Changes from API v2 to API v3

  • New resource: Version, to get version information.
  • New resource: My Passwords, to work with the personal passwords of the user (My Passwords).
  • Get information about the user making the call (who am I): GET /users/me.json.
  • GET /passwords/ID.json => additional returned field that indicates what permission has the user making the request on the password: "user_permission" can be read/manage.
  • GET /projects/ID.json => additional returned field that indicates what permission has the user making the request on the project: "user_permission" can be read/manage.
  • GET /projects/ID.json => additional returned field that indicates if the user making the request can create passwords on the project: "user_can_create_passwords" (true/false).
  • Allow the use of the advanced search operators (in all versions of the API).
  • Fix incorrect encoding of numeric strings as numbers in API responses (in all versions of the API) (released previsouly as patch 4.47.94.20150206).

Changes from API v1 to API v2

Basically, API v2 introduces support for expiry date and locking.

Specifically (this is also documented in the corresponding sections):

  • List passwords (and List passwords of a project): expiry_date (in ISO 8601 format: yyyy-mm-dd), expiry_status (0=no date or not expired, 1=expires today, 2=expired, 3=will expire soon).
  • Show a password: expiry_date (in ISO 8601 format: yyyy-mm-dd), expiry_status (0=no date or not expired, 1=expires today, 2=expired, 3=will expire soon).
  • Create a password, Update a password: expiry_date (in ISO 8601 format: yyyy-mm-dd, or null or '').
  • Support for locked passwords:
    • In lists: locked property (TRUE/FALSE) and can only see name and project.
    • In show: locked property (TRUE/FALSE) and can see more data than name and project if "X-Unlock-Reason" header supplied.
    • To lists users the "X-Unlock-Reason" header must be supplied. If not => 403 (forbidden).
    • To update (data, custom fields, security, delete, lock state): need to supply "X-Unlock-Reason" header. If not => 403 (forbidden).
    • Set a password as locked or not.
    • "X-Unlock-Reason" is only valid for the call, not the session (because there is no session).

In previous versions (v1):

  • expiry_date and expiry_status are not returned.
  • expiry_date cannot be set when creating or updating a password.
  • Locked passwords only return basic data (name, project).
  • Locked passwords cannot be listed its users, updated or deleted. 403 forbidden is returned.
Questions or Problems? Please contact our support department