API Documentation | MessengerPeople

The management API allows to programmatically retrieve and modify the fact checking specific data. The API is exclusively reachable via HTTPS. All endpoints are prefixed with /api/vversion. All data is transferred as and expected to have the content type application/json, encoded as UTF-8.

Authentication and authorization
Pagination, filtering and sorting
Rate Limiting
Further Reading
Webhooks
Webhook Calls
Agents
Research
- Comments
- Notes

If you miss anything here or have suggestions or simply want to ask a human being, you can send us a message at the bottom of this page. All messages sent via that form will be read by the development team directly.

To authenticate to the API, you will need to include your channel-wide API key as a bearer token:

GET /api/v0 HTTP/1.1
Host: factchecking.messengerpeople.dev
Authorization: Bearer {{YOUR_API_KEY}}

You can find your API key here. Please keep in mind that this token has administrative privileges for the entire channel, so make sure to keep it protected to prevent unauthorized access or data breaches.

All API endpoints that list records support generic mechanisms to paginate, filter, sort, and query items. This works by using a set of standard parameters in the query string:

To paginate, you may use the page and per_page query parameters. Depending on the resource, the maximum page size may have an upper limit other than the default of 100 records. By passing page=3, for example, you would retrieve the third page of all results with the default page size set. By passing ?page=3&per_page=20, you would retrieve the third page of all results for a page size of 20.
To retrieve the total number of records on the server, you can review the response headers. If a response contains a paginated result set, we add the X-Total-Items header to the response. It contains the number of records that match your current filters and search term.
To search for records, you may use the query query parameter. By setting it to a search term, a substring search will be performed in the fields allowed to search for this specific resource.
By passing ?query=example, the platform would search for any item matching this substring. While similar to the filter expressions, search queries allow searching multiple fields, possibly using advanced searching algorithms rather than a mere substring comparison.
Check the documentation of a specific endpoint to find notes about searches.
To sort records, you may use the sort query parameter. It can be used multiple times to sort by multiple fields. By passing ?sort=created_at, for example, you would sort by the created_at field in ascending direction. To search in descending direction, you would need to pass ?sort=created_at:desc. You can also explicitly request ascending sorting by passing ?sort=created_at:asc, though this is the default value and not strictly required. To sort by multiple fields, you may either pass multiple fields separated by a comma: ?sort=created_at:asc,foo:desc or add the query parameter multiple times: ?sort[]=created_at:asc&sort[]=foo:desc.
To filter records, you may use the filter query parameter. It can be used multiple times to apply multiple filters. Filters can be specified in a simple combination of field name, comparison operator and value. The following expressions may be used:
- Equality comparison: field=value
- Substring comparison: field:value
- Greater than comparison: field>value
- Greater than or equal comparison: field>=value
- Lower than comparison: field<value
- Lower than or equal comparison: field<=value
- Unequal comparison: field!=value
- Null check: !field
- Not null check: field
As filters are passed as query parameters, you will need to take care to properly encode them: An equality filter uses an equals sign, for example, which collides with query parameters. Therefore, you'll need to use the encoded variant %3D instead: ?filter=field%3Dvalue. We recommend to use a library that takes care of query parameter serialization to avoid any issues from broken filter expressions. The following examples use the un-encoded operators for improved readability. Filters may be chained bei either comma-separating the individual expressions: ?filter=field1:value,field2>42 or passing the filter query parameter multiple times: ?filter[]=field1:value&filter[]=field2>42.

While the API does currently not employ strict rate limits, we reserve the right to employ such measures at any time if we detect abusive behaviour beyond the existing characteristics our web application firewall scans for. This is nothing you should worry about, however, if you do not actively try to probe or damage the integrity of our platform.

As a web API, we make extensive use of HTTP status codes. This means that you can generally rely on the meaning of status codes as documented by MDN, for example. The following rules apply:

If a request to our API was successful, and has any data in its response body, we send a status of 200 - OK.
If a request to our API was successful, and caused a resource to be created, we send a status of 201 - Created. The response will include a Location header that points to the new resource.
If a request to our API was successful, but did not explicitly request information, we don't send superfluous response bodies. Therefore, the status code will be 204 - No Content. This also applies to requests that update or delete resources.
If a request to our API failed due to a missing, broken, outdated or otherwise invalid token, we send a status code of 401 - Unauthorized.
For most authorization issues (requests for information the account has no access to), we throw 404 - Not Found errors instead of 403 - Forbidden, with the reasoning here being that we don't want to disclose the existence of information. However, there may be specific cases where a 403 - Forbidden might be thrown.
If a request to our API failed due to a broken request body, an unknown content type or other parsing errors, or if the request body cannot be validated, we send a status code of 400 - Bad Request.
If a request to our API fails due to an error on our side, we send a status code of 500 - Internal Server Error. The platform is built with a heavy focus on returning usable error responses despite all else, so you should be able to find more information about the error in the response.
Some endpoints may have their own, unique rules regarding possible error codes. These rules should be outlined in the reference documentation further down on this page!

Sometimes, things break. That's okay! We have built the API in such a way that the errors are as helpful as possible, no matter whether its our software or yours that caused the issue.
Every error we throw will render as a nicely formatted HTML error page if shown in a browser, and a JSON object for API requests from other user agents. Both views include several details on the error:

The error message. This is a message for humans, for the most part, that we try to keep readable for non-technical folks. It should give a hint on what went wrong. If you happen to see an error message that is unclear or overly technical, please let us know.
A detailed hint. The hint contains technical details on what caused the error, and how to resolve it. This is actually directed at developers and might contain l33tsp3ak, too :)
If you encounter a hint that is unhelpful or vague, please let us know.
A correlation ID. This is a UUID generated specifically for your request that helps us locating the details of your request and the actual exception thrown in our monitoring systems. If you keep hitting an error and need help in debugging, tell us the correlation ID.
A stack trace (hopefully not!). In some environments, our platform will include full stack traces in error responses. You will likely never see them, unless if we invite you to a preview version. We'd like to ask you to keep the details of these stack traces confidential. They don't contain any dark secrets, and we're not shy about our tech stack, but might help attackers finding entry points.

An example response might look like the following:

{
    "error": "Not authorized",
    "hint": "Authorization header is missing from request",
    "correlation_id": "8fb6d7e7-861a-4de2-ac9d-494d81e4767a"
}

We also recommend to take a look at the MCP REST API for other resources, as it provides live updates for MCP users.

Webhooks


/api/v0/webhooks

Webhooks are HTTP endpoints called when something happens in our system, roughly speaking. You can create multiple webhooks and assign each of them to several events you would like to be notified about. As soon as one of those events occurs, we will send an HTTP request to each of your webhooks that is subscribed to this event.
Webhooks are a useful tool to inverse the control flow: Instead of regularly polling our API, you can instead react to events as they happen.

When creating a new webhook (or updating an existing one!), we will send a verification request to its URL. This is a security measure that benefits both you and us: It makes sure the URL you provided actually points to a valid webhook intended to receive messages from our servers.
First, we send an initial HTTP request to the webhook URL you provided. It contains a JSON object with two properties: verification_token and challenge. The verification token is an arbitrary value chosen by you during the webhook creation; the challenge is a random string generated by our servers.
Now, you should check the verification token: It should be a value hard-coded in your application code. If the token we sent matches the one in your code, the request did indeed originate from our servers, since the token is only known to you and us.
To finish verification, you must send a response with status code 200 and a JSON object in the request body that contains a single property: challenge. This property must contain the challenge you received from our servers.

If any particular event triggers a webhook in our backend, we will check whether any of your channel's webhooks are subscribed to this event. For all webhooks found, we will generate a JSON payload and attempt to send a request to the webhook URL.
Please note that we cannot share the IP addresses of our webhook workers with you, as these workers are dynamically spawned in a cluster and have ephemeral IPs that may change at any time. You can verify requests made from our platform by relying on the secret and verification token instead.
The full request, including body and headers, as well as the duration HTTP status code, body and headers of the response, will be stored and can be queried via the webhook calls endpoint later on.

Please make sure that your webhook endpoint takes no longer than 2 seconds to send a reply. Our webhooks workers are configured to time out after that and consider the webhook request failed, consequently setting the delivery status to 408 Request Timeout.
We need to do this to ensure individual webhooks are not blocking our delivery infrastructure for too long.

Webhooks revolve all around events. Events are fixed points in the execution flow of our application: Once a message has been received, for example, we trigger an event. If any of your webhooks are subscribed to the event in question, we send it an HTTP request, so your own code can react to any news on our platform. The following list describes all events available for you to subscribe.
If you feel there's something missing here, or you require a new event, please let us know!

message_received
A message has been received
message_sent
A message has been sent
notification_sent
A template notification has been sent
research_assigned
A research task has been assigned to an agent
research_created
A research task has been created
research_outdated
A research task has been marked as outdated
research_review_approved
A research task has been reviewed and approved for usage
research_review_rejected
A research task has been reviewed and rejected
research_review_requested
A research task has been submitted to review
research_sent
A research task has been sent as an answer
research_ticket_added
A ticket has been added to a research
ticket_assigned
A ticket has been assigned to an agent
ticket_closed
A ticket has been closed
ticket_opened
A ticket has been opened

uuid

Unique ID among all webhooks. You may use the UUID to address a specific webhook.
name

Display name of the webhook. This is a value you may freely assign that will be shown in the interface.
url

The HTTP endpoint we should call once this webhook is invoked. Must be a real URL, pointing to a server that has a valid SSL certificate.
secret

Optional secret we will include in an authorization header so you can ensure the request was sent from our servers.
verification_token

Token used during webhook verification. This token should be a value hard-coded in your application that we will send in verification payloads. If the verification token you receive matches the one you know, you can be sure the verification request was sent from our servers.
active

Whether the webhook is currently enabled and will receive requests. If it is not active, we will skip it during webhook emission. This field defaults to true.
events

All events this webhook is subscribed for.
created_at

The date and time the webhook was created. This value is automatically generated upon creation and cannot be modified manually.
updated_at

The date and time the webhook was last modified. This value is automatically updated and cannot be modified manually.

{
    "uuid": "f985c7e6-b752-4cb7-bad9-a2a4757207ad",
    "name": "Example Webhook",
    "url": "https://webhook.example.com/meta/webhook",
    "secret": null,
    "verification_token": "d2da1f67bc",
    "active": true,
    "events": [
        "message_received",
        "message_sent"
    ],
    "created_at": "2023-06-09T00:43:21+02:00",
    "updated_at": "2023-06-09T00:43:21+02:00"
}

List all webhooks


GET

/api/v0/webhooks

Lists all webhooks for the current channel, including the events they are currently subscribed to.

Create a new webhook


POST

/api/v0/webhooks

Creates a new webhook. Please be aware that the webhook URL must be a valid URL using the https scheme that our servers may access, as the URL will be checked and validated before the webhook is persisted.
If any error occurs during validation, a 400 - Bad Request will be thrown. This error differs from the default error format, as it includes details on the HTTP request to your server that failed. The error will look similar to the following:

{
    "error": "Failed to verify webhook",
    "hint": "The remote server would not return a success status code, or failed to complete the challenge",
    "correlation_id": "86248290-a605-4c31-9508-e79a3b034658",
    "response": {
        "status": 403,
        "content_type": "application/json",
        "headers": {
            "content-type": [
                "application/json"
            ],
            "www-authenticate": [
                "Bearer realm=\"token\", charset=\"UTF-8\""
            ]
        },
        "body": "{\"error\":\"unauthorized\"}"
    }
}

Retrieve a single webhook


GET

/api/v0/webhooks/uuid

Retrieves a single webhook by its UUID. If the webhook cannot be found, or if it doesn't belong to the current channel (as identified by the token), a 404 - Not Found error will be thrown.

Update an existing webhook


PUT

/api/v0/webhooks/uuid

Updates an existing webhook. Please be aware that if you update the webhook URL, the same restrictions as on creation apply: The URL must be a valid URL using the https scheme that our servers may access, as the URL will be checked and validated before the webhook is updated.
Only those fields present in the request payload will be updated. If the webhook cannot be found, or if it doesn't belong to the current channel (as identified by the token), a 404 - Not Found error will be thrown.

Deletes a single webhook


DELETE
 
/api/v0/webhooks/uuid

Deletes a webhook. This is effective (almost) immediately, so as soon as you delete a webhook, we won't deliver updates to it anymore. If the webhook cannot be found, or if it doesn't belong to the current channel (as identified by the token), a 404 - Not Found error will be thrown.

Retrieve the call log


GET

/api/v0/webhooks/uuid/calls

Retrieves all calls to this webhook. This is essentially a shortcut for the webhook calls endpoint, returning only the calls for a given webhook. If the webhook cannot be found, or if it doesn't belong to the current channel (as identified by the token), a 404 - Not Found error will be thrown.

Retrieve available events


GET

/api/v0/webhooks/events

Retrieves all events available for webhook subscription. This is a read-only resource. Events have two properties: caption, the name of the event, and description, a short description of the event.

{
    "caption": "message_received",
    "description": "A message has been received"
}

Webhook Calls


/api/v0/webhook-calls

As we make calls to your webhooks, lots of things could happen: The network could fail, or the request could be intercepted (thus breaking encryption), or maybe a proxy or your server is failing. Maybe our payload is incomplete or contains some new data you do not expect.
All these situations have one thing in common—they result in an error being thrown, and subsequently things are going to break down and stop working. To help you fix this situation as quickly as possible, we store the entire call to the webhook in our database so you can review it later on.
Of course, this is not limited to failed requests but includes every single HTTP call to your server!

What does »entire call« entail? We keep a copy of the body and headers of both our request and your response, as well as the status code of the response, and the duration from start to finish.

Please note that the API does currently not provide for a way to retry failed webhook requests. That is an item on our backlog, but there's no ETA yet.
If you're interested in having this capability, please talk to your customer success representative.

Obviously, this is a read-only resource: You cannot create webhook calls manually, however they will be created and updated automatically as soon as a webhook is called.

uuid

Unique ID for this webhook call. You may use the UUID to address a specific webhook call.
status_code

HTTP status code of the response as received from your server. If the call has not been performed yet, this will be null.
request_body

The request body as a string. This is the exact content of the request as we dispatch it to your server. If the call has not been performed yet, this will be null.
request_headers

The request headers as an object. The object will contain every header included with the request as a key, with the value being an array of the header's values in the request. As a header may be added to a request multiple times, this is always an array of string values. If the call has not been performed yet, this will be null.
Header objects are structured like the following:
```
{
    "Content-Type": [
        "application/json"
    ],
    "Cache-Control": [
        "no-store",
        "no-cache",
        "must-revalidate"
    ]
}
```
response_body

The response body as a string. This is the exact content of the response as we received it from your server. If the call has not been performed yet, this will be null.
response_headers

The response headers as an object. The object will contain every header received from the response as a key, with the value being an array of the header's values in the request. As a header may be added to a response multiple times, this is always an array of string values. If the call has not been performed yet, this will be null.
Header objects are structured like the following:
```
{
    "Content-Type": [
        "application/json"
    ],
    "Accept": [
        "application/json",
        "text/html"
    ]
}
```
duration

The full duration from dispatching the request until receiving the response as wall-clock time. Although this is a subjective value that includes a small amount of time spent in our infrastructure, it may give you a good estimation for the responsiveness of your webhook. As we cancel requests that expire the timeout of two seconds, you should make sure to keep this value as low as possible.
created_at

The date and time the webhook call was created. This value is automatically generated upon creation and cannot be modified manually.

{
    "uuid": "f985c7e6-b752-4cb7-bad9-a2a4757207ad",
    "status_code": 200,
    "request_body": "{\"event\":\"message_sent\",\"note\":\"payload omitted from example\"}",
    "request_headers": {
        "Accept": [
            "*/*"
        ],
        "Accept-Encoding": [
            "gzip",
            "deflate"
        ],
        "Authorization": [
            "Bearer debcdf6bb98a7f8cd27206244f7dabad"
        ],
        "Content-Type": [
            "application/json"
        ]
    },
    "response_body": "ok: webhook accepted",
    "response_headers": {
        "Content-Type": [
            "text/plain"
        ],
        "Content-Encoding": [
            "gzip"
        ],
        "Content-Length": [
            "20"
        ],
        "Date": [
            "Fri, 09 Jun 2023 00:43:21 GMT"
        ],
        "Server": [
            "nginx/1.16.1"
        ]
    },
    "duration": 0.0251112,
    "created_at": "2023-06-09T00:43:21+02:00"
}

List all webhook calls


GET

/api/v0/webhook-calls

Lists all calls to webhooks made from our workers.

Retrieves a single webhook call


GET

/api/v0/webhook-calls/uuid

Retrieves a single webhook call by its UUID.

Agents


/api/v0/agents

Agents, the users of your channel and employees of your company, are also the users of the fact checking platform. This API resource allows to retrieve and manage your agent accounts.
As agents are kept in the MCP system internally, they have a numeric ID instead of a UUID, as the other, fact-checking related resources do. Apart of that, however, they work just the same.

id

Unique ID for this agent. You may use the ID to address a specific agent.
email_address

The email address of this agent. This is the address we will send emails to and the username required in authentication steps. It must be a valid email address. Keep in mind the credentials for both MCP and the fact checking platform change if you update the email address. Additionally, the user will need to reconnect Slack, if the integration is enabled.
full_name

The agent's full name, consisting of first and last name. This will be shown in the interface to other agents.
profile_image

A picture of the agent. This will be shown in the interface to other agents. If no image is set, a placeholder image will be shown in the interface and this value will be null.
created_at

The date and time the agent was created. This value is automatically generated upon creation and cannot be modified manually.

{
    "id": 71166,
    "email_address": "[email protected]",
    "full_name": "Fact Checker",
    "profile_image": "https://cataas.com/cat/says/hi.jpg",
    "created_at": "2023-06-09T00:43:21+02:00"
}

List all agents


GET

/api/v0/agents

Lists all agents with access to the current channel, including the events they are currently subscribed to.

Create a new agent


POST

/api/v0/agents

Creates a new agent. As the fact checking API only allows for a subset of fields of the MCP API, several values will be filled with defaults. If you need additional control and fine-grained configuration, we recommend using the MCP API endpoint instead.

Retrieve a single agent


GET

/api/v0/agents/id

Retrieves a single agent by its ID. If the webhook cannot be found, or if it doesn't belong to the current channel (as identified by the token), a 404 - Not Found error will be thrown.

Update a single agent


PUT

/api/v0/agents/id

Updates an agent. As the fact checking API only allows for a subset of fields of the MCP API, several values will not be modified. If you need additional control and fine-grained configuration, we recommend using the MCP API endpoint instead.

Deletes a single agent


DELETE

/api/v0/agents/id

Deletes a single agent. This is effective immediately: Any sessions still opened by the deleted agent will be invalidated and their current tickets are cleared from the assignment. Please note that this operation can't be reverted. If the user cannot be found, or if it doesn't belong to the current channel (as identified by the token), a 404 - Not Found error will be thrown.

Research


/api/v0/research

Research is the fundamental concept powering the fact checking. A single research groups everything that belongs to an inquiry: Associated agents, tickets, messages, research notes, links and images and so on.

uuid

Unique ID for this research. You may use the UUID to address a specific research.
type

The type of research. Currently, the two possible values are text, and article.
url

The URL of an article associated to this research: This will probably be a link to an article on your website that refers to this topic. Feel free to include referral query parameters to the URL—if you send it to your users, our backend will shorten the URL anyway so the parameters won't be taking up message space.
If no URL is set, this field will be null.
status

The current status of the research. The status determines the workflow step the research is in and will be reflected in the user interface: A research may have the status open, in_progress, in_review, approved, rejected, outdated or, as a special case, deleted.
Deleted researches are still stored in the database but won't be considered for automatisms or shown in results both in the interface or in the API.
If you attempt to set an invalid status, a 400 - Bad Request error will be thrown.
image

The URL of an image associated to this research. Can be used in messages to your users.
If no image is set, this field will be null.
title

The title of a research. This should be the broad topic being researched. The title will be shown in API results and the user interface.
keyword

An array of keywords describing a research. Keywords are used to match a research against messages, so we can suggest it to agents in the user interface.
agent_id

The agent this research is assigned to. Generally, there are two types of assigment: A request to answer the questions covered by the research—this is what the agent ID indicates—and a request to review the research once the agent deems it complete. To keep the association between who originally wrote an answer, those are stored separately.
reviewer_id

The agent this research is assigned to for review. Generally, there are two types of assigment: A request to answer the questions covered by the research—this is what the agent ID indicates—and a request to review the research once the agent deems it complete. To keep the association between who originally wrote an answer, those are stored separately.
created_at

The date and time the research was created. This value is automatically generated upon creation and cannot be modified manually.
updated_at

The date and time the research was last modified. This value is automatically updated and cannot be modified manually.

{
    "uuid": "f985c7e6-b752-4cb7-bad9-a2a4757207ad",
    "type": "text",
    "url": "https://factly.in/fact-check-how-true-are-government-claims-about-fdi-flows/",
    "summary": "Recently, the government claimed that India received the highest ever FDI worth $64.37 billion in 2018-19. Here is a fact check of the claim.",
    "status": "approved",
    "image": null,
    "title": "Fact Check: How true are Government claims about FDI flows?",
    "keywords": [
        "government",
        "india",
        "fdi"
    ],
    "agent_id": 71166,
    "reviewer_id": 71169,
    "created_at": "2023-06-09T00:43:21+02:00",
    "updated_at": "2023-06-09T00:43:21+02:00"
}

List all researches


GET

/api/v0/research

Lists all researches.

Create a new research


POST

/api/v0/research

Creates a new research.

Retrieve a single research


GET

/api/v0/research/uuid

Retrieves a single research by its UUID. If the research cannot be found, or if it doesn't belong to the current channel (as identified by the token), a 404 - Not Found error will be thrown.

Update a single research


PUT

/api/v0/research/uuid

Updates a research. If the research cannot be found, or if it doesn't belong to the current channel (as identified by the token), a 404 - Not Found error will be thrown.

Delete a single research


DELETE

/api/v0/research/uuid

Deletes a single research. If the research cannot be found, or if it doesn't belong to the current channel (as identified by the token), a 404 - Not Found error will be thrown.

Retrieve the editor of a research


GET

/api/v0/research/uuid/editor

Retrieves the assigned editor of a research. If no editor is assigned, a 404 - Not Found error will be thrown.

Update the editor of a research


PUT

/api/v0/research/uuid/editor

Updates the assigned editor of a research. This will reassign the research to the new editor, and they will subsequently be notified about this. This special endpoint expects a single agent_id property in the request body, containing the ID of the new editor. If the new editor cannot be found or doesn't have access to the channel, a 404 - Not Found error will be thrown.

{
    "agent_id": 1234567
}

Retrieve the reviewer of a research


GET

/api/v0/research/uuid/reviewer

Retrieves the assigned reviewer of a research. If no reviewer is assigned, a 404 - Not Found error will be thrown.

Update the reviewer of a research


PUT

/api/v0/research/uuid/reviewer

{
    "agent_id": 1234567
}

Comments on research allow for social collaboration on ongoing work: Leave remarks for yourself or colleagues in an out-of-band manner.

uuid

Unique ID for this comment. You may use the UUID to address a specific comment.
type

This field is a remnant from the internal architecture and will be removed in future revisions of this API. It should neither be used nor expected to exist. For the time being, it's hard-coded to the value comment.
content

The content of the comment as a plain-text, UTF-8 string.
author_id

The ID of the author of a comment. Must be a valid ID of a user that has access to your channel. All comments must have an author; if you intend to add comments from a bot account, consider creating an agent for your bot.
created_at

The date and time the comment was created. This value is automatically generated upon creation and cannot be modified manually.
updated_at

The date and time the comment was last modified. This value is automatically updated and cannot be modified manually.

{
    "uuid": "f985c7e6-b752-4cb7-bad9-a2a4757207ad",
    "type": "comment",
    "content": "this is an example",
    "author_id": 71166,
    "created_at": "2023-06-09T00:43:21+02:00",
    "updated_at": "2023-06-09T00:43:21+02:00"
}

Retrieve all comments on a research


GET

/api/v0/research/uuid/comments

Retrieves all comments on a research. If the research cannot be found, or if it doesn't belong to the current channel (as identified by the token), a 404 - Not Found error will be thrown.

Retrieve a single comment on a research


GET

/api/v0/research/research-uuid/comments/comment-uuid

Retrieves a single comment on a research by UUID. If the research or the comment cannot be found, or if one of them doesn't belong to the current channel (as identified by the token), a 404 - Not Found error will be thrown.

Create a comment on a research


POST

/api/v0/research/uuid/comments

Creates a new comment on a research. If the research cannot be found, or if it doesn't belong to the current channel (as identified by the token), a 404 - Not Found error will be thrown.

Research notes are intended to keep notes during researching a topic. There is no minimum or maximum length.

uuid

Unique ID for this note. You may use the UUID to address a specific note.
type

This field is a remnant from the internal architecture and will be removed in future revisions of this API. It should neither be used nor expected to exist. For the time being, it's hard-coded to the value note.
content

The content of the note as a plain-text, UTF-8 string.
author_id

The ID of the author of a note. Must be a valid ID of a user that has access to your channel. All notes must have an author; if you intend to add notes from a bot account, consider creating an agent for your bot.
created_at

The date and time the note was created. This value is automatically generated upon creation and cannot be modified manually.
updated_at

The date and time the note was last modified. This value is automatically updated and cannot be modified manually.

{
    "uuid": "f985c7e6-b752-4cb7-bad9-a2a4757207ad",
    "type": "note",
    "content": "this is an example",
    "author_id": 71166,
    "created_at": "2023-06-09T00:43:21+02:00",
    "updated_at": "2023-06-09T00:43:21+02:00"
}

Retrieve all notes on a research


GET

/api/v0/research/uuid/notes

Retrieves all notes on a research. If the research cannot be found, or if it doesn't belong to the current channel (as identified by the token), a 404 - Not Found error will be thrown.

Retrieve a single note on a research


GET

/api/v0/research/research-uuid/notes/note-uuid

Retrieves a single note on a research by UUID. If the research or the note cannot be found, or if one of them doesn't belong to the current channel (as identified by the token), a 404 - Not Found error will be thrown.

Create a note on a research


POST

/api/v0/research/uuid/notes

Creates a new note on a research. If the research cannot be found, or if it doesn't belong to the current channel (as identified by the token), a 404 - Not Found error will be thrown.