Traversal API

Routes begin with /data/ and correspond to assembl.views.api2. These routes are automatically generated from the classes which are defined, and their properties can be traversed. The first element after /data/ is the external name (cf assembl.lib.sqla.BaseOps.external_typename()) of a Python class for which we want to list the instances, or to access a specific instance. It can be followed by the database id of an instance of this class (for example: /data/Discussion/6 ). Some classes (Discussion, Preferences) also have unique names which can be used in traversal: /data/Discussion/slug ).

View defs

An API call can contain a parameter “view” (for example: /data/Discussion/?view=partial ). Its value is the name of a view def. View defs are JSON files which are defined in assembl.view_def. A view def defines for each class the properties which the server is allowed to send back to the client, or which are allowed to be modified by a POST/PUT API call.


The API URL of an object instance can be followed by /@@collections . This will list all collections available from this instance. A collection of this list can be one of:

  • a relation (in the ORM sense: OneToMany or ManyToOne)

  • the backref of a relation (this is an inverse relation, which has been defined in the other class of the relation, not in this one)

  • a collection which has been defined via extra\_collections. In this case, the JOIN operation has been coded manually. (assembl.views.traversal.CollectionDefinition.decorate_query(), assembl.views.traversal.CollectionDefinition.decorate_instance(), assembl.views.traversal.CollectionDefinition.contains()).


Uses the generic API.

Get user notifications

All notifications, for this user, this discussion: /data/Discussion/6/all\_users/2/notification

A specific notification: /data/Discussion/6/all\_users/2/notification/1

Specific formats, append:

  • /mail: Raw email

  • /mail\_html\_preview: Preview the html part of the notification mail (if any)

  • /mail\_text\_preview: Preview the plain text part of the notification mail (if any)


Those actions are based on pyramid named views. (not strictly REST, but useful for debugging)

/process\_now: Notify the celery_notify celery task to try processing the notification immediately A global equivalent exists for all notifications: /data/Notification/process\_now


Get all posts for a discussion:

/api/v1/discussion/1/posts You can append a view, such as ?view=id\_only

Delete a message (Superadmin):

DELETE /data/Content/3244

Permission lookups:

GET /api/v1/discussion/2/permissions/add\_extract/u/

Frontend notes: Specific messages are adressed with urls such as


Metrics and statistics (work in progress, api under flux): Ex:


Discussion preferences:

Raw data: (does not include permission cascade, use it to edit) /data/Discussion/1/preferences

Discussion preferences:

Cooked data (includes permission cascade) /data/Discussion/1/settings(/{key}) (In frontend: models/discussionPreference.js)

User Namespaced KV store:

/data/Discussion/1/user\_ns\_kv/{namespace}(/{key}) in particular /data/Discussion/1/user\_ns\_kv/preferences(/{key}) which contains the overrides found in user-corrected preference data: /data/Discussion/1/all\_users/current/preferences(/{key}) (In frontend: Ctx.getPreferences, which is taken from a tag.)