Podium

• New contactWatches a complete, bounded resource snapshot. Existing records establish the first baseline; new records start the workflow afterwards. Failed pages retain the saved place. Polling follows your workspace plan; scans are limited to 4,000 records.
• Contact changedWatches a complete, bounded resource snapshot. Existing records establish the first baseline; new records and changes start the workflow afterwards. Failed pages retain the saved place. Polling follows your workspace plan; scans are limited to 4,000 records.
• New appointmentWatches a complete, bounded resource snapshot. Existing records establish the first baseline; new records start the workflow afterwards. Failed pages retain the saved place. Polling follows your workspace plan; scans are limited to 4,000 records.
• New conversationWatches a complete, bounded resource snapshot. Existing records establish the first baseline; new records start the workflow afterwards. Failed pages retain the saved place. Polling follows your workspace plan; scans are limited to 4,000 records.
• Conversation changedWatches a complete, bounded resource snapshot. Existing records establish the first baseline; new records and changes start the workflow afterwards. Failed pages retain the saved place. Polling follows your workspace plan; scans are limited to 4,000 records.
• New messageWatches a complete, bounded resource snapshot. Existing records establish the first baseline; new records start the workflow afterwards. Failed pages retain the saved place. Polling follows your workspace plan; scans are limited to 4,000 records.
• New invoiceWatches a complete, bounded resource snapshot. Existing records establish the first baseline; new records start the workflow afterwards. Failed pages retain the saved place. Polling follows your workspace plan; scans are limited to 4,000 records.
• Invoice changedWatches a complete, bounded resource snapshot. Existing records establish the first baseline; new records and changes start the workflow afterwards. Failed pages retain the saved place. Polling follows your workspace plan; scans are limited to 4,000 records.
• New reviewWatches a complete, bounded resource snapshot. Existing records establish the first baseline; new records start the workflow afterwards. Failed pages retain the saved place. Polling follows your workspace plan; scans are limited to 4,000 records.

• List locationsList of all the locations that the caller has access to. If the `cursor` parameter is used then all other parameters will be ignored. This is to avoid confusion if passing both a `cursor` and other parameters which would change what data is being returned. The `cursor` keeps the filters of the request that returned it, so every page of a `createdAfter`, `createdBefore` or `updatedAfter` query stays filtered. Required scope: `read_locations`.
• Get locationGets a single location by its uid. Required scope: `read_locations`.
• Send messageSend a message. A message can only be sent on behalf of a user if they have the necessary permissions to send messages in: conversations assigned to them, conversations assigned to others, and unassigned conversations. Required scope: `write_messages`.
• List usersList of all the users that belong to any of the locations that the caller has access to. If the `cursor` parameter is used then all other parameters will be ignored. This is to avoid confusion if passing both a `cursor` and other parameters which would change what data is being returned. Required scope: `read_users`.
• Get userGets a user. Required scope: `read_users`.
• Create appointmentCreate an appointment. Required scope: `write_appointments`.
• List appointmentsList appointments for the locations the token can access, oldest change first. `since` is an inclusive (`>=`) filter on `updatedAt`, the time the appointment record last changed. `order` sorts by `updatedAt` and defaults to `asc`. A `cursor` carries the `since`, `order` and `locationUid` of the listing it came from, so send it alone; any of those sent alongside it are ignored. Follow `nextCursor` until it is `null` before advancing `since`: `since` is inclusive and `updatedAt` values are not unique, so moving the watermark mid-traversal skips records sharing the boundary timestamp. Required scope: `read_appointments`.
• Get appointmentGets an appointment by UID. Required scope: `read_appointments`.
• List reviewsList of all the reviews that you have access to. The reviews are sorted by `createdAt` date, with the most recent appearing first. If the `cursor` parameter is used then all other parameters will be ignored. This is to avoid confusion if passing both a `cursor` and other parameters which would change what data is being returned. Required scope: `read_reviews`.
• List contactsList all contacts. Required scope: `read_contacts`.
• Create contactCreate a contact. If a contact with the same phone number, email, or conversation uid is found it will update the contact. Required scope: `write_contacts`.
• Delete contactDelete a contact with a conversation uid, email, or phone number. Required scope: `write_contacts`.
• Get contactGet a contact with a conversation uid, email, or phone number. Required scope: `read_contacts`.
• Update contactUpdate a contact with using a conversation uid, email, or phone number as an identifier. Required scope: `write_contacts`.
• List conversationsList all conversations. If the `cursor` parameter is used then all other parameters will be ignored. This is to avoid confusion if passing both a `cursor` and other parameters which would change what data is being returned. `since` is an inclusive (`>=`) filter on last activity, and matches the `lastItemAt` field in the response -- not `updatedAt`, which is the record's own timestamp and moves independently. When polling, overlap your `since` value with the previous poll and de-duplicate by `uid`. Both parameters are optional. Sending neither returns exactly what this endpoint has always returned, including both open and closed conversations. Required scope: `read_messages`.
• Get conversationGets a conversation that has previously been created. Required scope: `read_messages`.
• Update conversationUpdate a conversation. Required scope: `write_messages`.
• Get reviewGets a single review by its uid. Required scope: `read_reviews`.
• Create review inviteCreate a review invite link. Required scope: `write_reviews`.
• List messagesRetrieve limited number of messages from a conversation. `since` and `order` are optional; sending neither returns exactly what this endpoint has always returned. If the `cursor` parameter is used then all other parameters will be ignored. The cursor carries the `since` and `order` of the traversal it came from, so a page walk stays on the same filtered, ordered listing. Required scope: `read_messages`.
• Get messageRetrieve a message from a conversation. Required scope: `read_messages`.
• List templatesList all templates. Required scope: `read_templates`.
• List invoicesList of all invoices that match the query parameters. Required scope: `read_payments`.
• Get invoiceGets an invoice that has previously been created. Required scope: `read_payments`.
• List payment accountsLists the Payments accounts for the locations the caller has access to. Use the `uid` of an account to identify which Payments account an invoice was paid into. If the `locationUid` parameter is not used then the data will be based on all locations that the caller has access to. Note: This route requires that your application gets allow-listed. See: `KumeteWeb.Plugs.RateLimitV4` for reference. If you need to add a new application to the allow-list, please contact the team responsible for Kumete [marketplace-team]. Required scope: `read_payments`.

No actions match that.